Python isn't the fastest language around so speed-reliant code is difficult to write.
On the other hand, it's certainly fast enough to do the sums involved in moving a few hundred sprite objects around the screen -- one lets the rendering system do all the looping work.
The advantage, from a learning point of view, is that much of the boring fiddly work of who owns which bits of memory is done for you so you can focus on the more interesting parts.
Many of us grew up writing games in a mix of BASIC and assembly language on 8-bit micros, and the kinds of games which worked well there can be written these days in Python much more easily. M&B is, as Sean says, a bit out of reach, but rogue-likes, 2D puzzlers and platformers, shoot-em-ups and so on are within reach (only with better graphics than the 8-bits!). I wouldn't be surprised to find that with a little extra work, things like Starglider could be done in Python these days.
The trick is to design a game that doesn't involve large amounts of data.
Large, of course, means something slightly different these days. A z80 instruction to block copy memory costs 21 cycles per byte copied. You only get 50-100 thousand cycles per 50th second TV field on most 8-bit micros. So you can realistically only copy a few kilobytes of memory per frame.. I had a quick naive play with some code and python on its own is capable of copying 400k per frame. So even in plain old python you've got 100 times as much processing power as we had back in the early 80s...
 LDIR, for reference.