I realize that there are some advantages. The network between the Worker and a Google datacenter is probably much faster than the network from the user to the Worker. Also, Firestore in particular can be geographically replicated so that the database is closer to your user. But I'm not convinced that these benefits outweigh a more traditional (and more flexible) architecture.
Think of all of the random conditionals that your http routes have; "is the client posting a correct data structure" or "is this a valid OAuth token" or "am I requesting something that I already have cached" or rate limiting or the list goes on and on.
All of that kind of stateless route level logic that may not need to hit a data store is a perfect candidate for an edge worker, because once you have that deployed, you can concentrate more on business logic within your main application.
For example: "I have a valid OAuth token, I have established my identity, now issue an S3 pre-sign request and forward the resulting URL to the browser to download a protected file". Doing that within a worker will absolutely speed up your user experience by a couple hundred milliseconds at least.
There are a lot of performance advantages along every step of the way, as you mention. I think you can look at this from many different lenses beyond performance.
A big advantage was how fast and easy this was to get up and running. Simplicity is key here - it's a simple API written in JavaScript (no config, VPS, etc necessary).
The other really important thing is scalability - when workers.dev went live, we didn't have to worry about being able to handle the spiky workload (preregistration sites end up failing quite frequently). This scales infinitely.
[Disclaimer: Product Manager on Cloud Firestore who thought this was an interesting use-case]
