It's also trivial to serve read requests from a caching layer or via a CDN. At any sufficient scale, you're probably going to need a CDN anyway, whether your database is replicated or not. You don't want every read to hit your database.
I guess that's acceptable because people don't really look for the feedback; why do users add the same thing to the list twice, why does everyone hit the refresh button after adding an item to the list, etc. It's because the bug happens after the user is committed to using your service (contract, cost of switching too high; so you don't see adding the cache layer correspond to "churn"), and that it's annoying but not annoying enough to file a support ticket (so you don't see adding the cache layer correspond to increased support burden).
All I can say is, be careful. I wouldn't annoy my users to save a small amount of money. That the industry as a whole is oblivious to quality doesn't mean that it's okay for you to be oblivious about quality.
(Corollary: relaxing the transactional isolation level on your database to increase performance is very hard to reason about it. Do some tests and your eyes will pop out of your head.)
Multi-region databases with read replicas face the same issue
Right now your choices are: run a database in on region and:
1. Use the weird HTTP header based cache API with a boring CDN
2. Write a second, JS based app with Workers or Deno Deploy that can do more sophisticated data caching
3. Just put your database close to users. You can use us for this, or you can use something like Cloud Flare Workers and their databases.
My hot take is: if something like Fly.io had existed in 1998, most developers wouldn't bother with a CDN.
Weirdly, most Heroku developers already don't bother with a CDN. It's an extra layer that's not always worth it.