There are a few reasons. Number one, stability issues from heap fragmentation. http://docs.micropython.org/en/latest/reference/constrained.html#ram http://docs

There are a few reasons. Number one, stability issues from heap fragmentation. http://docs.micropython.org/en/latest/reference/constrained.html#ram http://docs.micropython.org/en/latest/reference/constrained.... Even if you are careful about manual allocation, Python is not a compiled language, and the interpreter will frequently request heap allocations on its own. So if you expect a program to run for a long time without crashing, you'll probably need to use much less memory than the system has available. It's also quite slow. That's not a huge issue since modern microcontrollers are fast and you can write your own .mpy modules in C, but it does affect power consumption. It's also pretty high on the "drama" scale as far as OSS projects go. Last I checked, there was a brewing split between the original maintainer and one of the largest contributors, and Adafruit have already gotten frustrated enough to make a hard fork called CircuitPython. Personally, I would use it a lot more if I could trust it to run stably. For reference, I've used it in a Cortex-M0 clock which can run more or less indefinitely, but needs 16-32KB of RAM just to read an I2C clock and set some 7-segments. And when I tried to set up a simple wireless MQTT sensor with a supported Cortex-M4 board, I couldn't get it to run longer than a few days before the application crashed from memory fragmentation. So from my perspective, it is only usable for trivial tasks, and even if it were more stable, I'm not sure which fork would be the right choice for long-term development. Still, it's an excellent educational tool and I always like to see more of those.