The real trick with AWS, IMO, is figuring out what you want to do yourself vs what you want to have hosted. For example, they offer a hosted cache such as memcached or Redis. For my app, I run Redis myself as it required roughly 15 minutes of work total to set up and maintain in 2014. OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow (even though by the specs, it was using a more powerful VM than the EC2 box I was running my instance on).
Basically, once you grok AWS, things become more productive AND you don't need to spend time on doing things like setting up VLAN's, transferring data between boxes, etc. You can do cool things like detach a virtual disk from one VM and attach it to another, rather than pushing 100 GB's of data over a network. This, AFAIK, is not something that Linode or Digital Ocean can do.
Having said that, DO is great for lots of things. It's a good place to experiment and to run lots of really small things. For me, that's side projects or things that I am trying out before thinking about moving them to the "big iron".
> OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow
These two statements are contradictory.
You would have been better off just renting a dedicated host for your DB and doing the tuning yourself (either in person or getting someone to do it) - because the AWS offering is slower than your own instance, and database is a service thats often ripe for easy optimisation by using a dedicated host/cluster of hosts vs virtualised host(s).
My point about physical was just another common optimisation for performance critical DB servers, you could probably get close to bare metal speed with the flexibility of virtualised by using a "single VM on hardware" model that some providers offer now.