Good points, I'd moved to python for embedding and shimming myself and then got bit cause SWIG had forced Cpython when there were other options later. I do still very much like the simple syntax though.
I like it sometimes more and sometimes less. For instance, the "everything's a string" parsing rules mean comments can cause parse errors.
Ha, that's the very reason I used it at first!
#!/bin/sh
# the next line restarts using tcl \
exec tcl "$0" "$@"
...
I just go so annoyed with is it /usr/bin/perl or /usr/local/bin/perl or ... And is it awk or nawk or ... And somebody told me this trick with Tcl and I was like, "I'll just use it for this simple script and be done with it."
Issues I have with Tcl:
* The syntax is as idiosyncratic as a Lisp, but has few of the advantages that Lisps get for homoiconicity.
* uplevel/upvar is a janky way to get metaprogramming. Compare metaprogramming in Tcl to that of Japanese Tcl errr Ruby.
* The Tcl runtime is outmoded.
I could probably think of others.
There's also the fact that Tcl's vaunted integration with C code has pretty much become par for the course in high level languages. I didn't find writing Ruby extensions to be any more painful than writing Tcl extensions. Modern high level languages also expose full-featured FFIs, so you often don't even need bindings.
Tcl was ahead of its time! It was a good embedded high level language before virtually every large project recognized the need for embedded languages. And the event-based model that Tk forced on it turned out to be pretty useful for network servers. It was a great choice in the late 1990s.