Well, it's wrong to start with microservices, that's a given. Both Martin Fowler and Sam Newman tend to agree on that and also speaking from experience I found that in order to have a shot at designing microservices, you must have something to indicate their domains - plain DDD won't help from the start, too much time will be wasting drawing boundaries.
But ... I'm always annoyed by clickbait titles. "Build monoliths first" would be more relevant. Also because the problems underlined are not those of microservices.
When you say "Managing Data Is a Nightmare" - stop. If you have separate databases that need sync otherwise they are inconsistent, they are coupled. Therefore, these are not microservices. They are part of a distributed monolith at best.
"More Time Setting Up" - yes but not for the reasons you state. When you have duplicate code, you have a shared library with proper versioning, end of story. you don't need to define modules in each service, you need to import them. "Building APIs or a messaging system to facilitate this is non-trivial" - only if you haven't practiced proper versioning or messaging schemas or APIs.
"Microservices Work Best for Large Teams" - that depends on organisation and largely depends on experience. In my company this depend on project. We have projects where the accent is so much on "micro" (even though that's not necessarily important) that we have a person managing 2-3 microservices. In most cases, a team of 3-4 devs manages 3-4 microservices together. It's never a team per service.
"DevOps Is More Complicated" - no, Ops is more complicated. If you really implement devops as a practice, it's exactly the thing devops was designed to solve. A team managing a set of microservices owns them fully, including all the pipelines, deployments, configuration, etc. As a side-effect, if you don't practice devops, you can't really have microservices.