Until then, ignorance is bliss.
In my experience with RDS as a MySQL admin, Amazon was not using sane defaults for quite some time, which resulted in a remarkably non-performant product. Thankfully, they listened to feedback, so over the course of a few years the MySQL RDS instances started to become much more dependable and useful. I'd be happy to use one today, which is something I couldn't have said too long ago.
And even with RDS, having a DBA available (even just as a consultant) is still quite useful - it's unrealistic to expect your developers to write ideal SQL. You can get a long ways with RDS if your queries and schemas are well tuned.
It is an multi-AZ DB, which is very different to multi-region. (Availability Zones (AZs) are within a DC, regions are separate DCs)
See this Re:Invent 2014 talk about AWS Innovation At Scale http://mvdirona.com/jrh/talksandpapers/JamesHamiltonReInvent... => Slide 9: "Each AZ is 1 or more DC, No data center is in two AZs, Some AZs have as many as 6 DCs"
Also, just to clarify, you can do multi-region RDS read-replicas for MySQL: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_...
Are they suggesting that every time you need to apply a security patch, you'll have to build a new server and cut your traffic over to it? That sounds like a lot of DNS and Load Balancer config updates (mutable!) even if the newly patched server builds are 99% automated.
The idea of black-box appliances has been around a long time, and it has its place in the modern infrastructure, but I'm not sure it really solves the problems they are trying to solve (which sound more like change management issues).