But if you're looking for "reason" I think that falls on not re-doing the same thing over and over again.
It just starts a lame language war thread while being dismissive of and incurious about the thing being discussed. Things the site docs ask you to avoid as they reliably generate more noise than interesting conversation.
I hope I don't have to work with some young fool who decided without trying that perl, an incredibly well documented language, is "too hard" and instead signed our whole team up to work with some experimental 3 month old language with who knows what weird bugs and quirks, none of which youll find info about on stack overflow, because almost nobody has ever used it Reminds me of the days about 10 years ago when all the kids were obsessed with no SQL and MongoDB for use cases that were smaller than SQLite -- purely because they were scared to learn SQL
You'll understand where I'm coming from after you get more experience and have had multiple jobs where you had to maintain architecture with poor choices due to an inexperienced original author using cool shiny tech that offers little advantage over the more mature tech, and you spend much of your time working around and maintaining something that has no stack overflow coverage at all
Besides, "runs anywhere bash does" isn't really useful for a personal project. Work is where you're likely to run into a weird variety of legacy machines, not in a personal project where you have more control.
Regardless, the weird aversion to hearing advice that can just be disregarded if it doesn't apply to your case baffles me.