I can't imagine a microservice architecture that does not require more devops work than a comparable and sane monolith. Your second and third sentences haven't convinced me.

Developers and operations often love microservices.

If you make one small change you only have to test and deploy that one microservice. Instead of having to redeploy the monolith which not sure if you've ever done that before is often terrifying.

Not quite. With a monothlic, it's an overhead to migrate data, because one small mistake will take your application down.

So, in real world, it takes more overhead to manage a monothlic than a microservice architecture.

With microservices, if you make a mistake and take part of your application down, aren't you worse off because only part of your application is running and is now in an undefined state?

You really need to think that comment through first.

If you're a bank then it's fine if your notification microservice goes down because at least you can still accept payments, handle deposits, transfer money etc.

In almost no situation is there a case where having no availability is preferred over partial availability.

It's fine to have only one part of the application down, instead of the whole go down.

Each part of application is ran by different roles/functionalities.

At one company I was at we moved to microservices to reduce ops work.

Scale independence was a huge value add for us.