I was involved in a software development project last year, in which the entire remote development team of 20 people got fired, because the software architect implemented a bunch of best practices, design patterns and state-of-the-art frameworks, without any thought as to how this would impact development time. The problem was that he was the only one who was familiar with most of this stuff, so there was a very steep learning curve for the rest of the team, who one by one either dropped out or became totally unproductive. After 18 months in which he burnt his way through the budget, with very little to show the client by way of results, the project was drastically scaled back. So this is not just about straw men. People like this really do exist.
Things like best practices become more important the larger the team. Are you suggesting the project would have been more successful if they had been less concerned about code organization and unit testing (or whatever you mean by "best practices")?
The problem was not the use of best practices per se, but the uncritical use of these practices. For example, it's good to use design patterns, but not every pattern is appropriate to every situation. We got to a point where it might take a full day to make a change to a table, and then make the corresponding changes to all the various repositories and entities. Similarly, it's good to use the latest technologies, but using beta versions of unpublished frameworks was a bit over the top, both because documentation was scarce and because they were still buggy.
