First of all, if you have anything mission critical, you need to run it in a high availability config, this is easy for stateless microservices, but when it comes to running your DB, you start renting three boxes instead of one or two and configuring them accordingly.
And then you setup your Backup Infrastructure for disaster recovery, Glacier needs a replacement after all. No problem, just more disks(?) on a few more boxes(?) and bacula(?), better in a different Datacenter just to be on the safe side, it would be nasty if you whole rack gets fried and your data with it.
Don't forget to backup your configuration, all of it. Loadbalancers, Server Environment Variables, Network (do you have an internal DNS?), Crontabs, some businesses need their audit logs stored etc...
On the infrastructure level there is lots and lots of stuff you can do and you won't ever really need AWS, you'll just spend significantly more time finding and administering the right solutions than just using the AWS Solutions where you'll find a treasure trove of great tutorials and can relatively cheaply pay for support.
If you then pay someone on top for 24/7 management/monitoring of your dedicated stack so that your team doesn't have to get up at 3 am because one of your VMs disk fills because some stray logfile is filling the disc, many of the savings you had by setting it up on a dedicated server go out of the window because the management partner needs to train their people to look into your infrastructure. AWS only Management Partners are just light-years cheaper because they can streamline their processes much better.
You could also hire your own team of admins...
Sure AWS is a beast with its own surprises, but overall the cost/benefit ratio is still very fair even if you factor in all the "surprises"(many of which your management partner will probably know about). Having layered support is really something beneficial aswell.
If something is wonky with RDS, you get to call your management partner if he didn't detect it before you, who if he can't tackle it himself can call AWS technicians. This gets you much much further than you would get elsewhere. The outside the world is paying for (for example) perconas consultants or someone similar if the problems grow over their team's head.
Sure, at some point in a companies growth, depending on how technical the operation is, there might be a time where an admin team and colocation/dedicated boxes make sense, where AWS technicians will scratch their heads etc., especially if you have some very very specific tasks you need to do.
But for most people this is far off if ever.
Another big thing that rarely gets mentioned is research into exactly what hardware to purchase and how to configure it. Do you know what compute hardware you should purchase? There are 10s of vendors and thousands of options. What about network hardware? Do you know which switch is the best for your stack?
With a cloud vendor all of these questions disappear.
Even if you make a mistake in your cloud provisioning, it's easy to correct; just shut it down and start over. Make a mistake buying your own hardware and you have to live with it for 3 years or pay purchase more hardware.
I think people tend to forget or ignore all of these costs when evaluating cloud providers. You look at the total bill each month and are surprised that it cost that much. However, the costs for your custom built architecture are likely higher, but they are spread out over more time and more projects.
The 2 extremes you cite might be good for some people in a narrow set of contexts, it makes sense to include other possibilities when evaluating your hosting options.
Did I stutter? I said no colo. You need to be ridiculously large for colo to be worth considering.
If you have customers with enterprise needs paying enterprise prices, you need to keep your SLA. Think finance, e-commerce, etc.
If your Infra Provider has the same SLA than you do, you have problems and should do the math and think about backup infrastructure or what ever else is necessary to have a chance of upholding that SLA.
Edit: I just now see that you misunderstood me. With "backup infrastructure" I meant an infrastructure to do backups, not another new infrastructure to sit there and collect dust awaiting disaster. That's mostly not necessary.