The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database, but nothing prevents your monolith from also talking to different DBs.
And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!).
If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic.
And since it's likely a nonlinear problem it's hard to map the problem-solution space, hard to get a good mental model for it, so we use the next best thing: stories. We have success stories and parables on what not to do. (And whole conferences dedicated to telling them :))
For deploying they are nothing but a very large hindrance.
It's much easier to test them in separation also. Deployments are low risk, not much need for coordination with other teams, etc.
There are components that have a heavier load, so we run more of those. Not really a big difference compared to simply running a few more monoliths and configuring them to only handle certain requests... but that's already a given here.
I don't have strong opinions either way. Teams/companies should do what works for them, and they should spend some time on improving it so they can be more effective. (Because most people/teams/companies have a "good enough" complacency inertia/bias.) And most solutions work in both setups. (Eg. making builds fast requires a divide and conquer strategy anyway. Do you build modules/packages separately and link them in the end? Do you build containers separately? Same thing. Do whatever works.)
As long as your bug is well behaved and decided to keep itself into a single microservice... and you somehow know what microservice it is, then yes, it's much easier.
Let's take a typical monolith. You'll be serving endpoints that: - Are CPU intensive - Are memory intensive - Are I/O intensive
They are almost always heavy on some part, but not all. And definitely they are not uniformly all relying on the same amount of resources.
Now, you scale out horizontally, adding instances of the same size because each of these monolithic instances need to be capable of serving the entire domain without impacting tail latencies. Some part of your application becoming more resource intensive? You'll be bumping up the sizes of the entire monolith because you are essentially needing to do the equivalent of provisioning for peak load.
Contrast this with microservices (which I'm not arguing are a silver bullet), you can run your memory intensive part of memory optimized instances, and run your compute intensive parts on compute optimized instances.
That's the part about scalability.
Now, the more interesting part (for me, personally) is reliability. You are decreasing your blast radius of a bad component/thread/process taking down your entire monolith service, and instead compartmentalizing it into limited subparts of your entire API or application.
Finally, as you mentioned, microservices do help guide you towards better choices when it comes to structuring your data. You can do this with monoliths as well (and should), but it doesn't come naturally, and having a single data store is the main reason I see teams run into scalability issues :)
---
Addition: Some thing I don't see many people talk about is the ability to address tech-debt in Microservices. My experience has been that it is an enormous benefit to have made you domain smaller for when it comes to making changes that require sweeping across the whole codebase. Examples include upgrading language versions (e.g. Scala 2 -> 3, Haskell 8.10 -> 9.2), upgrading frameworks, introducing stricter compilation checks (e.g. TypeScript and strict: true).
These easily end up being either insurmountable or year-long projects in a monolith, where it's very hard to incrementally benefit from the work because they are often by nature all or nothing changes.