I talked with the Unladen Swallow guys sometime after the project was canceled. They said that the main issue was not getting Python to run fast on LLVM, where they said they had some really encouraging results. Instead, it was:
1. Bugs in LLVM which they had to spend a lot of engineering effort working around. This is probably much less of an issue now, with Clang, XCode, Julia, and Rust all being used in production with a good deal of success.
2. Compatibility with the C API. This was considered a "non-negotiable" for Unladen Swallow's design, and one major reason they started by forking CPython rather than building from scratch on LLVM. The problem is, the C API makes a lot of assumptions about how objects are laid out in memory, how they are memory-managed, how they are accessed, etc. If you must support defining & calling methods from C, there's a lot less freedom to, say, stick a trampoline in the method preamble or a PIC at the call site or switch to using a tagged representation of pointers and ints. That means that the VM has to fall back on the interpreter (and possibly waste cycles converting & marshalling data) for a lot of things that are supposed to be fast, which kills many of the real-world performance gains.
V8 had the luxury of defining its own C interface. I've often wondered whether a Python that gives up C extension compatibility could get similar speed gains - I even ran the idea by a former Python core team member who worked on my team at Google, and he said there was no theoretical reason why not. But then, Python without C extension compatibility would be Python without Numpy, Scipy, scikit-learn, PIL/Pillow, JSON, StringIO, and many other critical packages. At that point you might as well start over with a new language.