Agree that the functionality needs to be tested in-whole. But the delta in time is very large when the feature level tests have to be run on the monolith & they can be avoided when they are tested on the micro service.
A "well-designed monolith's" code architecture would be very similar to microservices - with separated modules, but in-process function calls instead of remote API calls.
If you do large-scale integration tests that cross module boundaries in the monolith, then you should also have the same tests of the full deployment with microservices. If you test each microservice independently, then you could also run tests for each module independently.
A decade later, and you have a lot of business logic in stored procedures in your database and now hear grumbling from coders who don't know or don't want to learn SQL. (And, to be fair, it does make it harder to scale the engineering team if everyone needs to be proficient at SQL.)
Neither availability nor technical scaling concerns were the reason we started to transition away from our monolith. We were regularly hitting 4 nines of availability (measured by "orders coming in") and had scaled to well over $1BB in revenue essentially on a single database for most of the site functionality. Above average engineers and ops, and way above average DBA team was key to making that happen.