I think B still holds:
A. Snapshots does not mitigate the issue.
B. A.k.a. force to failover via external scripting. In other words, even master won't get promoted automatically, the external script will schedulely fail over within period of time; although the situation will become the db uptime fitting with fail over period (to let the dba kicking-in), but at least better than other options (at least the clients get their db back)
C. Larger instances does not help with not promoting to master, plus sync and downtime (2 weakest links) have to be considered.
D. In real world, the client definitely does not want to change their application, whereas changing different db (e.g. Postgresql -> MySQL) even same brand of db required ETL jobs.

May be answer D ?

Highly available PostgreSQL instances do not have a separate failover instance the way MySQL instances do.
This has the following consequences:
There is no concept of replication lag, as there is for MySQL instances. As long as the secondary zone is healthy, failover can occur.

By the way MySQL replica should be promoted to standalone manually only.