Most people are doing what exactly?

I think there are two important points here. First, that is at best a beta level proposal, and I wouldn't bet the well being of my family on it. I'll be very happy when it stabilizes, but I'd stick to outputting plain html for the engines.

Second, this sounds far more complicated than simply outputting html from your web app. This thread is about decoupling UI from the backend for a clean design. Using this approach is far less clean than outputting the html directly.

If you are doing a web client, that is dynamic, correctly, you should already be reflecting a distinct UI by a URL fragment. having a web proxy run on a seperate box than you production server and routing request for a search bot is not that difficult. There is no custom logic involved you are just proxing through a headless browser. It's not beta it is just that Google is trying to standerdize the practice. Where you get in trouble is if your proxy is giving something different to the bot than the end user is getting. It really is a simple as if a request comes from a bot agent service it from the proxy box, it's a router rule.

you have to setup and maintain this separate proxy and headless browser. This is surely more complicated than outputting html from your web app.

Not if you are supporting multipal clients and want to seperate out your concerns. The point is that the UI should be decoupled from your core application logic. The advantages that brings, negates the few hours one will spend setting up an out of the box server and proxy to support SEO. There are many web apps that don't even have SEO as a problem domain.

You are arguing that this approach is better, therefor it isn't more complicated. You realize that isn't valid logic, right?

No I am arguing that setting up a route based on an agent does not require custom logic and therefore removes the problem from a development issue.

It would be just as valid to argue that a fire-walled web environment is more complicated than one that is not fire-walled, while true it ignores a host of realities, but it is accepted that the advantages of security outweigh the complexity of a firewall.

What I am saying is that much like a firewall, it is a task of configuration and not custom development and therefore given its ease of implementation, the advantages outweigh the marginal complexity (I am arguing that it is marginal) that it brings.

As well, I am arguing that much like a firewall ejecting this problem domain out of the application, creates a simpler solution. You can implement access security in your application, but it is commonly accepted that rolling your own is a bad idea. The advantages of dynamic user applications are clear and I am arguing that those advantage clearly outweigh the need for this simple solution, if SEO is even a problem domain of your application, it is not for some.