I think there might be a middle ground here that avoids introducing a BFF to be maintained and operated: in the back-end, introduce "faster moving" endpoints that are specifically targeted for front-end clients and that don't commit for long-term support.
What do you see as the difference between a BFF and "fast-moving endpoints"? To me, BFF is an unpublished API for internal use only. I can change BFF whenever I want (as long as I do the corresponding change to frontend) and don't have go through the effort of building+maintaining facades/wrappers/whatever for backwards-compatibility.
If you have a 3rd party using an endpoint, it kind of changes things. Providing short-term instead of long-term BC is maybe slightly less effort, but any BC at all is an order of magnitude more work than none.
With no BC, you would basically say "Hey on Thursday afternoon we're deploying a new version and the old one goes away -- be ready!". That nearly guarantees a 3rd party will have downtime, and is frankly a very hostile way to treat them. If I was the 3rd party I'd either be hounding your business for a long-term BC commitment for anything I use, or complaining about how it's a garbage API that constantly breaks on us and advocating switching away to a competitor ASAP.
