And just to clarify, I've been both the "shinny new framework" and the "I can make it 0.1% more efficient" guy at different points in my admittedly short career (still a senior though). These days I'm the "make it work" guy but only after suffering the negative outcomes of the other two a little too much. You only really "get it" after doing the "wrong" way first.
I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly.
The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph:
"Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery).
Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it).
But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen.
I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you.
The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart.
Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway.
"Individuals and interactions over processes and tools"
If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.