Installing Python is no big deal.
I have installed Python on such a machine. It was a big deal and nothing I would ever attempt just to get a make-like utility working. It would be far less work to replace that utility with Make than to get Python onto the machine.
You may have heard it told, but I've tried it, and I disagree. What do you mean by "leave their original use-case"?
Sorry; I get a bit abridged at times. What I meant is that Make alternatives normally are born from a specific need. A group wants to build Java programs (for example) and come up with a tool that works better than Make for that.
But then it almost invariably (so far) turns out that the tool that works great for the original use case is lacking features, or lack flexibility, or has dependencies that make it unsuitable for very different kind of projects. Make-replacements that really are general enough to fully replace it are no easier to learn and use than Make itself. It seems for all its cruft and oddities, Make does seem to represent a floor in the complexity needed to support all the different situations you may encounter.
I have tried a number of alternatives over the years because I was frustrated with Autotools (which, rather than Make itself, is what people often really complain about). Finally, for one project I bit the bullet, got myself a book and really learned Autotools properly. And found out it's not bad at all, just unintuitive until you get a good explanation. There is some cruft there of course; but many oddities are due to the portable nature of the tools, and others are simply conventions that modern languages don't follow - they're not wrong, just different.
If you really want to replace make I suspect the best replacement would be - Make. That is, define an optional "new Make" mode that is not backwards compatible, with cleaned up syntax and parsing rules; the surface stuff that people get annoyed by.