Worse off with microservices
I worked at a company which had a monolithic application used by customers globally. It had been built in a pretty old fashioned way but worked well and generated lots of revenue. It was version controlled (git) and the deployment process was simply doing a git pull on to the production server. All testing was done manually with, you know, actual humans doing sanity checks on work they'd done. If something disastrous occurred it was easy enough to rollback to a working commit.
They then decided to develop applications using a microservices architecture. It was still version controlled (git) but also had unit testing and other tools in the deployment procedure including Jenkins. There were countless dev instances - all of which used deployment tools. Some of the developers got a boner about things like linting their js, but thought that meant doing sanity checks on their own work was less of a thing because "I've run my tests".
The end result was that in the monolithic approach people deployed stuff less often and were more keen to check it before it went into production. The deployment process was simple, fast and worked. There was little overhead with it.
In the microservices world there were perceivable gains of being able to deploy stuff "faster and more reliably". But these didn't actually translate into benefits for the customers of the software.
To me, the mindset of microservices and trendy deployment processes isn't about quality for end-users or even getting things done efficiently. It simply creates a load of work and overhead *elsewhere* so that you can press The Magic Button(TM) and claim to be really efficient.
Just because you can deploy stuff fast doesn't mean it's a good idea. In fact it shifts the mindset to constant deployment and that's when quality tends to suffer and customers are disregarded.