I would say in a lot of cases understanding that there are some basic failures is probably a great starting point to cleaning up the development effort. There's not much else I can say other than that, considering how vague OP's post is.
"Good" engineers will get things done and use common tooling to their advantage. This requires actually understanding the principle behind the tools, not just shoving things in and hoping it all magically works.
If you have a lot of "good" practices that are supposed to make it easy to move code around and you find that things just keep breaking, one could reasonably assume that it's simply highlighting an underlying issue. I'd start figuring out which engineers (and management) is causing more work for our organization than they're putting out.
What I think we're seeing from OP is lot of "in name only" practices.
Some good practices aren't a good fit for a particular organization. Moving the discussion to whether your engineers are "good", rather than whether they understand the organization's needs, is reductive.
If you want to develop better practices in an industry, saying the practitioner should be "good" isn't very helpful. Of course they should be good! But unfortunately, despite the trope, we can't all hire the best, and part of the reason we have best practices is to work well without only hiring the top 1% of engineers.
An example from my experience (mentioned in another comment)- microservices are a good practice in many larger orgs, because a big piece of what they solve is political- but the overhead of running a distributed system at a small org often isn't worth it.
I put "good" in quotes for a reason. I never said "hire the best"; that isn't a requirement for anything that was stated.
There shouldn't really be a measurable overhead of running a distributed system, at least in the context of microservices. I strongly disagree with the sentiment that a distributed system isn't "worth it" at smaller organizations. I'm part of one, and it helps keep things flexible while increasing reliability of the "overall" system(s).
But that's neither here nor there. One shoe size won't fit everyone, but OP ran down a gambit of things and seemed to have issue with each one. It is exceedingly unlikely they are doing anything eccentric enough to the point of proclaiming CI is just a bandaid on the broken concept of microservices. I will contend that the source of OP's insights are... misappointed, and by breaking down efficiencies and flexibility they're merely masking certain underlying problems.
What's more probable? An organization hired some wrong people, or a generic list of strongly supported practices over the course of two to three decades are to blame for an organization's failings? I guess that's my take on it.
