Deadlines and goals are fatal to the success of any software project today. And that is so for a very simple reason, you have to always drive towards something under well defined clear timelines.
This is very essential for two reasons. The first being measurement and continuous improvement. The second being you must decide what is a acceptable time for something to get done, and stick to it and adjust pace accordingly(The definition of a deadline). Else all it leads to overly delayed projects.
I have worked in a similar set up you described for a year or so. Have never seen such clueless roaming about in my whole life. Last time I heard they are still developing. I have done more work in a month than what they have done in say half year.
The reason is simple, pace again has a metric - Its, how fast?
I didn't describe this setup, but it sounds to me like they are using Kanban. Properly executed Kanban should have Queueing and WIP limits to prevent clueless roaming, make sure tasks get completed, and provide feedback. If something doesn't get finished in an acceptable amount of time you hit the WIP limit, a red flag is raised, and that task becomes everyones priority. If you regularly hit the WIP limit then you have a problem that needs to be addressed.
If you don't set these limits then you are absolutely correct. In this perfectly acceptable scenario you do need deadlines, however I'd argue that adjusting pace isn't the correct step. Here you should remove low priority unfinished features from the deadline, maintain a sustainable pace, and use features completed as your metric.
http://blogs.balsamiq.com/team/2011/09/07/pace/
tl;dr Don't work overtime, work sustainably.
All your other issues are with differences in pay, which is exactly what the article is advocating against.