I was on an MFE team earlier this year. It was sold to higher-ups as being for both, but I think in most cases it's bad for both. IME, it was sold in terms of code code-reuse by providing things like shared navigation bars, shared authentication logic, etc.
My team, at least, did not have the necessary support structures in place to help others who wanted to maintain their own UI. I see this mostly when crossing framework/language boundaries (mixing React + Angular in a SPA, as it was in my case). They declare microfrontends, but then all the component libraries were all React-based anyways.
It just ended up being a mess of N deployment processes, N build systems, N storage buckets, zero standardization whatsoever, and mountains of technical debt, all without much benefit.
...but if you're all working in the same language/framework where that component/style-lock-in is acceptable, why would someone use a microfrontend to begin with? Can the organization not set up a single repository with different teams contributing to it? One deployment, one build system, one storage bucket, and standardization?
IMO CODEOWNERS is the original and best "microfrontend" solution for small-to-medium-sized teams working on a single product. If you have hundreds or thousands of engineers (think FAANG) working on a single experience that just HAS to be a SPA, then maybe you have the resources to build out those support structures and actually get MFEs to work on an organizational level.
In the vast majority of cases, however, I see it as a bandaid on an organizational problem that's eaten up because it's an interesting technical challenge for senior engineers to think about (someone made a great comment about "drawing the perfect box"), and because management thinks it's a cool trend with benefits they can grok.