It's a tricky sweet spot PyPy has. Certain tasks that need CPU power but not too much CPU power and you want to spend time to make it run in parallel but not too much time to make it run across many machines.
(By no means am I a PyPy or CPython expert. Just toyed with them and want to understand the bounds...)
1) Point a metadata variable at my git repo
2) Spin up 100 GCEs
3) Each will pip install requirements.txt from the git checkout
4) Each will read a metadata to get the command and run it. (Could hardcode run.py or something).
Realize not everyone has this sitting around, but you can do it in an afternoon. Then gives you instant Python supercomputer for anything you want across many projects.
From my experience, one of the biggest issues with PyPy is that it's not a magic pill you take and suddenly all your Python code runs faster -- that's how they "sell" it. But in many cases, the idiomatic code for CPython results in slow PyPy execution, and idiomatic PyPy code results in slow(er) CPython execution.
That means that you have to refactor your code, and whereas you won't be breaking compatibility with CPython, your CPython performance will (most often) suffer. So, unless you're the sole user of your code, or you have control or decision power over most of your users, (or you just don't care to keep good CPython performance) your project might not benefit: "yeah, in PyPy it runs 2x faster, but 80% of our clients use CPython and are complaining over a 5x slow down -- ditch that code and get back to the previous version" may end up being the feedback from someone above you in hierarchy.
Don't forget about the ops guys using it for automation!
For actual real world apps with a lot of IO, your PyPy benefit is kinda small.
For actual number crunching, I guess. Which is the whole scientific side of Python.
Python is weird that it is 50% webapp hipsters ala Ruby, and 50% scientists in lab coats sitting in the lab crunching.