You may want to read this section: https://blog.heroku.com/archives/2014/2/3/heroku-xl#understa...
Performance dynos give you much higher performance and much better consistency, resulting in dramatically reduced tail latencies over 1X and 2X dynos.
Choosing performance dynos for a high-traffic or performance-sensitive app is definitely not "compensating for some other part of your stack being broken"; in fact it's a very smart choice.
You can call these issues "bold decisions." In my opinion, it reads more like, "We don't know how to fix the problem. If you really want to pay for it, we will let you skip our routing layer and solve the problem yourself."
It is a bit disappointing. However, I've never had to write a routing layer to handle 60,000 requests a second, so I can't really fault them.
Python may be on the wrong side of this, though, as long as Gunicorn is the de-facto standard WSGI server for Python apps on Heroku.
Amazon hasn't, but there are a reasonable number of simple PaaS competitors these days:
Microsoft's Azure (http://www.windowsazure.com/en-us/pricing/details/web-sites/): ASP.NET, PHP, Node.js, Python
Red Hat's OpenShift (https://www.openshift.com/): Java, Ruby, PHP, Node.js, Python and Perl
Nodejitsu (https://www.nodejitsu.com/): Node.js
XL Dynos let you throw money at the random routing problem which helps routing efficiency at the expense of spend efficiency (b/c they are a lot more expensive and scaling down to 1 XL dyno is still pretty expensive).
In my opinion, if you're using anything other than 1X dynos on Heroku you are compensating for some other part of your stack being broken.
We're probably months away from Heroku having some serious competition in the super easy PAAS space. Heroku's high prices have summoned competitors en masse, and by some stroke of luck Amazon has not really made a serious effort to encroach on Heroku's profits.