Operationally, you have different issues. Some approaches work better for a small infrastructure, and some work better for a big one.

Monoliths are easier to run and monitor. A friend of mine worked at a company and their sales-stuff was just a big java monolith. Deployments are simple - just sling a jar-file on 5 servers. Monitoring is simple, you just have 5 VMs or later on 5 metal servers with this java monolith on it, so you can easily look at it's resource requirements. You have 5 logs to look at.

If I was to bootstrap a startup with minimal infrastructure, just dumping some monolithic code base onto 2-3 VMs with a database behind it would be my choice. This can easily scale to very high throughput with little effort.

However, this tends to be slow on the feature development side. Sure, you can make it fast, but in practice, it tends to be slow. Our larger and more established monolithic systems have release cycles of 6 weeks, 3 months, 6 months, 12 months, ... This makes updates and deployments exciting, and adds lead time to add features. And yes, I know you want to deploy early and often to minimize the number of changes to minimize impact and unknowns, but this is the way these teams have grown to work over the years.

The more modern, microservice based teams just fling code daily to production or weekly at most. Safely. The deal is if they cause a huge outage, we slow down. There was no huge outage yet. This allows these teams to move at crazy speeds. A consultant may be unhappy about some UX thing, and you can have it changed on test in 2 hours and changed in production at the end of the day. It's great and fun and makes many expensive developers very productive. That's good.

The drawback however is complexity at many layers.

Like, we need 20 - 30 VMs of the base infrastructure layer to run until the first application container runs in a new environment. That's a lot. That's basically the size of the production infrastructure we had 6 - 7 years ago. Except, the infrastructure from 6-7 years ran 1 big monolith. This new thing runs like 10 - 15 products, 900 jobs and some 4000 - 5000 containers.

This changes so many things. 1 failed request doesn't go into 2 logs - the LB and the monolith. It goes through like 8 different systems and somewhat fails at the end, or in the middle, or in between? So you need good monitoring. You have thousands of binaries running in many versions, so you need to start security scanning everything because there is no other way. Capacity Planning is just different.

Smaller services allow the development teams to make a lot more impact, but it has a serious overhead attached to it.