I want you to deliver a good user experience too. I agree that one request and response to the users client is easy and has all the benefits you describe.
On the other hand, I think applying a specific application’s client-to-server REST API towards a generic server-to-server (an evolution of a federation protocol) is a mistake. Example done right: When a user clicks “Follow” in Pleroma, the client browser app doesn’t hang and wait for a confirm/deny from the server because they want to do it all in one synchronous round trip: it progresses whenever the server asynchronously gets an “Accept” received. It could be a synchronous UI-to-server and asynchronous backend, But for that use case it wouldn’t make sense to stare at a UI spinner. This probably doesn’t apply to your use case though. I won’t claim asynchronous processing is easy but lots of languages, frameworks, and apps make it tractable. I also don’t know the state of your specific application so I don’t have any concrete suggestions.
I think we’ve brainstormed your original generic question to come up with general purpose answers. If none of them work for how you want your specific application to function because of speed-of-development, incompatibility with existing implementation, and a synchronous requirement, that’s fine. I can’t argue against those.
I will be trying some of our general ideas out in the future, and I hope others will adopt it.
Edit: Reflecting more, I guess I’m of the opinion it is actually harder and more error prone to do things synchronously in a dynamic, asynchronous, federating world.