On one hand, monoliths will always be simpler to work with, at least until some point in time where their complexity grows to a point where working with them is a drag on everyone's morale and productivity.
Depending on how they're built, they could still scale horizontally, unless you've written a "singleton" application where having more than one instance and routing traffic between those would break something.
I'd say that a lot of the benefits of microservices and adjacent approaches are actually cultural: having multiple decoupled components lets you focus on whatever the "main" ones are at any given point in development, mostly doing maintenance work on others, whilst still limiting breakages.
And should it come to pass that some of the more boring components will eventually rot away (e.g. be stuck on JDK 8 or Python 2 or whatever) and will need to be rewritten based on what EOL you might run into, then you can mostly do that without affecting the rest of the system. The opposite also applies - you can upgrade 9 out of 10 components to JDK 11 even when one cannot be upgraded, instead of that one module holding everything else back in some monolithic system.
That said, there are lots of complexities to microservices and it's easy to mess things up - I've seen projects where I'm the first person that figures out that some shared code should actually be a Maven/pip/npm package in Nexus/Artifactory instead of just copying and pasting code across codebases, because nobody has put in the work to set everything up properly before me. Don't even get me started on day 2 concerns like tracing and debugging, which the article touches upon.
Other times, even modular monoliths might run into issues because people aren't good enough with writing decoupled code without too many common dependencies (unless forced by the language and its mechanisms to have proper separation), or aren't up to par with utilizing feature flags and such properly.
I think that at the end of the day, all code rots and eventually is hard to work with, which also affects entire frameworks or even languages: https://earthly.dev/blog/brown-green-language/
Your architecture will sometimes have concrete technical benefits or characteristics to take into account, but a lot of the time most of the actual effects will be organizational - how you will or won't be able to build everything, who will be responsible for what and what risks any particular deployment or version bump will carry.