I think this is sort of a "barbell effect" thing. Both models can work very well, but you can't really do both, you have to pick your approach and commit to it.

This reminds me of something I realized fairly late (maybe embarrassingly so) into my career. For the longest time, I had all these opinions about how software should be made, that is, universally, and would often feel very frustrated and discontented because nobody seemed to want to do things the right way.

But then I finally realized at some point that what was really going on was that different projects can be very different, and different approaches make more sense for different things. To use extreme examples, a single instance of a typical website-with-some-behavior vs. the control systems for a spacecraft. It's perfectly fine to build that website in a blitz using a CMS or framework with bog standard components and limited testing. But all you're going to manage with that same approach in the latter case is to crash your spacecraft.

But I also realized that where I was going wrong was in trying to impose my desires onto whatever project I happened to be working on, rather than imposing them onto my choice of what to work on. So I started thinking harder about what kinds of things I wanted to do, and being more deliberate in finding those projects, and convincing people to bring me onto them. (With somewhat mixed success of course... career development is hard enough when just going with the flow, let alone adding on conditions...)

To bring it back on topic, the analogy I'm drawing is: If you really want to do formal verification in all your projects, you shouldn't work on websites! And if you really want to pay attention to all the small little niceties, you shouldn't build a business with tight margins that are made up in volume!