A startup should be using a monolith until it becomes a victim of its own success and then should migrate thoughtfully to microservices only when it has to. It also requires a very heavy investment in devops and tools since microservices will fail in production in every which way possible. It also requires a huge investment in metrics and alerts and logging otherwise you will have no idea what is wrong with your now too-complicated production system.
While I generally agree with you in the vast majority of practical cases, it can make sense in some circumstances, namely, if there is a very clear logical abstraction between one service and another.
A microservice is just another layer of abstraction, similar to functions, classes, files, libraries, and programs, but even higher up the food-chain, and it comes with its own characteristics and peculiarities. If you have high confidence that one component is (1) logically extremely different from all of the other components, (2) has no side effects, (3) is not I/O bound as it's going over a network, and critically, (4) is on a separate development timeline, then you have a solid candidate for a microservice.
1. Always be backwards compatible in protocols and data formats.
If you store data on disk or in a table you V1 and V2 tables need to be generally compatible.
V2 should always be able to read V1 tables. This helps with rollouts.
In an ideal case V1 should gracefully handle V2 tables. This helps with rollbacks.
2. Service to service communications work between V1 and V2.
If you don't want downtime you have to gracefully handle the situation in which V2 is rolling out. In a zero-downtime deployment config like blue/green V2 instances can get requests from V1 instances and vice versa.
Monorepos don't help with these situations. These are just engineering practices that have to be upheld by the team. Monorepos will make the atomic source code updates applied across the codebase easy.
1. Stop all old servers before starting the new ones -> downtime, might be acceptable 2. Have your clients handle the fact that they might hit vN or vN+1 of your services.
But in reality, you're still facing same issue - let's say your components X and Y are updated in monorepo. You want X in production, but not Y - so now you have to invent something on top of monorepo to capture this. Another words back to square 1.
Regarding startups, in my experience they start feeling this pain when they already have 5-6 microservices. But YMMV - depends on a lot of factors.
In my experience this is not always the case and the problems creep in in other places that are not easily statically checked or tested, but which come up at runtime, e.g. specific runtime content/data, or serialisation of some message/object that happens at runtime.