It's not political that microservices owning well-defined slices of a pie can't cater to the frontend's every whim without creating a dependency spaghetti everywhere that you have cross-cutting concerns. It's just common sense.
If you're arguing that most microservice vs monolith decisions represent a political and not a technical decision, I'll grant you that.
I don't think it's necessarily bad. In fact it is quite an elegant solution to issues between frontend and backend teams. I just think it's a great example of Conway's law. Conway's law (IMO) was never a negative thing, merely an observation of the realities of software development.
Your post brings up an interesting angle which is that the frontend and backend people can have different expectations of what the backend should actually do (perhaps leading to dependency spaghetti). In this case, introducing a BFF can be a way to isolate that from the rest of the architecture.
100%. A backend API can be used from multiple frontends. Just one from my experience working for an electricity provider, API from Desktop webapp, android mobile app, IOS mobile app all retail customer facing. Then from a Sales pipeline for new customers in a CRM app. From B2B customers (Electricians building new homes requesting connections) in a different web app.
If you're arguing that most microservice vs monolith decisions represent a political and not a technical decision, I'll grant you that.