For this kind of tool, where performances are definitely not important, I'll pick Python, Ruby and Node all the time. I assume that pip, bundle and npm already did their job and installed everything I need. Then I'm able to look at the code, change a few lines and run it again with only a text editor. The extra steps to download the source code and go through a compiler are not worth the trouble.
On the other hand, a language & tooling that by default compiles to a static executable, such as Go, means no dependency trouble or installation steps at all, now or in the future. Just copy 1 file to all your machines and you have that command available.
If the software is open source, you can still change anything with your text editor and recompile the executable, usually with a single command (go build, IIRC.) Additionally, you can keep all the executables for all your versions and modifications.
Try to do that with Python, when the change you need is somewhere deep inside a library. At best you'll spend hours setting up multiple Virtualenvs; at worst it will just be impossible. Case in point, you can't use a Virtualenv for ntfy on OS X of you want desktop notifications (for whatever reason.)
Today I dumped a not-insignificant amount of time into trying to package ntfy into a single exe on Windows (using PyInstaller. It sort-of works, but was way way more painful than it needed to be. Python packaging still sucks in 2016. Go is way ahead of Python in that regard, but comes with its own quirks (GitHub by default, always uses the HEAD version of libraries, GOPATH)
I'm not familiar with PyInstaller but I wouldn't do anything similar with scripting languages. They are meant to be distributed as scripts so I'm not surprised it took you all that time. Why didn't you use pip to install on (I suppose) those other Windows machines?
There are similar problems with Ruby when people want to distribute executables. I remember I googled a solution that made a friend of mine happy (he had to deploy on multiple Windows machines, I don't remember what I suggested him to do) but still it's the wrong way to go. If creating a single executable is a hard requirement then yes, they are the wrong languages to solve your problem.
