This viewpoint doesn't translate to reality in my experience. Monolith or not, engineers care about working product if they are incentivized to care about working product (and if they aren't, they don't).
Code is code. Cognitive load is cognitive load. Doesn't matter how you organize it. Unless your company is still very small and simple, there's no single team that is going to be able to understand how the entire system works (and take ownership of every part of it working properly). I've worked in many monoliths where you still had to have "cross team meetings and project management every time you want to ship a feature".
> engineers care about working product if they are incentivized to care about working product
Places that set up the correct incentives are usually very rare. Maybe hedge funds or some finance places which give you a decent chunk of the profits your code makes but that's about it.
Every other place pays you the same "meh" salary and the quickest way up is to job-hop frequently, in which case resume-driven-development takes priority over "working product". That's how you get cargo-cult over-engineering, everything else be damned since you will be gone by the time the consequences emerge anyway.
(also you have "startups" where over-engineering is usually a desired feature as it gives them a justification to grift more VC money to keep their unsustainable business afloat further).
Honestly, in my experience there's nothing wrong with this line of thinking as long as you also consider that the product you're shipping to other devs is in service of a much more important and larger product/service in itself. Thinking of your service as a product keeps you thinking of the use cases, the potential errors and the DX of what you're shipping which is a good thing I say as long as you're not building pies in the sky. As with most things, it comes down to good planning
The key word here is DX. If a team is exposed to how the DX of their owned service or library enables others in the company to build things that bring smiles to customers' faces, they'll be able to better design for their downstream teams' experiences, finding the right balance of keeping API churn low while building for future flexibility. This is true whether the API boundary is over a network or over a function call.
That said, microservices have the added problem that if you don't get the culture and boundaries set just right from the beginning, it's harder to change. They're good for small domains where boundaries are defined, and many even-early-stage startups have some of those, but it's unlikely that the primary interface for customers is included in that.
Code is code. Cognitive load is cognitive load. Doesn't matter how you organize it. Unless your company is still very small and simple, there's no single team that is going to be able to understand how the entire system works (and take ownership of every part of it working properly). I've worked in many monoliths where you still had to have "cross team meetings and project management every time you want to ship a feature".