This stands as an interesting broad strokes story from a developer's experience at a growing company, but worth keeping in mind it's one specific scenario and one perspective on it.
In the generalizations-from-this-instance part of the essay, watch for two false dichotomies—"developers that care about getting things done fast with little technical debt and hate having PMs" vs "mercenary developers who like doing one small thing at a time without architecting things themselves, don't find fast ways to do things and ps like cars and money instead of hacking".
And "no PMs or process at all" vs "way too much process causing poor development time investment".
The best developers, team leads, PMs, etc know when to introduce new processes and team members and when not to. And, importantly, how to tailor processes to each team member to make them as effective as possible. And they work together collaboratively to solve problems—estimating and discussing features flexibly, not tossing pie in the sky specs and finished products over the fence.
In this instance it sounds like they didn't do a great job of working with existing scrappy developers' potential, but instead supplanted a new framework (eng/PM) they had seen work before, and the blunt hammer of that move destroyed a lot of potential the early team had invested in. It sounds like there was a general communication issue that was crippling the team even before a producer and new hires came in.
I've seen a few teams now grow from no dev process to combinations of issue trackers, estimates, specs etc. Around 14-20 developers it becomes nearly inevitable for someone to take on a high level production role and someone to take point for engineering reliability, whether those are official job titles or not.
Often this period coincides with when early team members move on. It's rad when growing companies find ways to keep those early, scrappy hires with deep historical product knowledge in productive roles as the company grows and shifts priorities from staff-leanness and product-speed to staff-scale and product-predictability. But that's often unfortunately not what happens, and it can be extremely painful for both early team members and those trying to evolve the company. (Growing pains!)