As I see it, none of the queuing stuff is really controversial.

> It's so easy to see what everyone is working on, run reports to see how long things took

This, on the other hand is usually what's controversial, and the reasoning behind that is that it often leads to management using past data as a stick to drive "faster" future development, with silly statements like “Well, the average plugin took 2 days to write, why is this one taking 7 days? Oh it must be that the person doing it is lazy. Better give them negative feedback on it and tell them it can affect their promotions”.

The example is contrived, but the motivations and behaviors are very real. Competent developers tend to leave companies where they are constantly badgered about stuff like this by managers who have never developed software. In the extreme case (very few organizations are this bad, but they do exist), all you end up with is the remaining ones who know how to show that they are doing a lot of work, but are generally afraid to show their lack of knowledge in any area for fear of being dinged by the data-equipped management for it.

Since this is not conducive to the technical health of a software development team, estimation practices that purport to be unrealistically accurate are what's looked down upon.

We had a ticketing system and one guy in our group had between 60% and 80% more tickets than the rest of us. So it would seem we were all slackers, however he took the tickets that took like 2 minutes to do (password resets, account unlocks, etc...), meanwhile i would get stuck troubleshooting a production performance issue that would consume hours. Management didn't care what the ticket was, they liked to see pretty numbers of tickets completed.

I might be the only one who had this experience, and i am not saying ticketing systems are bad, they are extremely useful, as long as everyone knows how they work.