Surprisingly enough, this was not among the reasons cited in RMS's original "Why you should not use Tcl" post: http://www.vanderburg.org/OldPages/Tcl/war/0000.html
-Tcl is not Lisp.
-At that time Tcl was being developed by an Evil company: Sun Microsystems.
At the time, TCL was being pushed heavily for this purpose. I had a very low opinion of TCL, basically because it wasn't Lisp. It looks a tiny bit like Lisp, but semantically it isn't, and it's not as clean. Then someone showed me an ad where Sun was trying to hire somebody to work on TCL to make it the “de-facto standard extension language” of the world. And I thought, “We've got to stop that from happening.” So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. The idea was that we would have a Scheme interpreter designed to be linked into applications in the same way TCL was linked into applications. We would then recommend that as the preferred extensibility package for all GNU programs.
Thing about extension languages is that they tend to be nice languages to write code, so people write a lot of code in them, and suddenly your app is 95% written in the extension language. Scheme is the language I know that grows best from a simple extension language to a full-fledged mature programming language.
By the way I wrote a toy, buggy and ugly scheme implementation in pure Tcl a year ago: http://wiki.tcl.tk/25512
And most of those systems were pretty old, so it's not like you had a lot of better options back in the days. Tcl was pretty awesome in the mid-90s.
Most Java programs that replaced those enterprise tcl systems were a lot worse than their predecessors.
For a new project? Maybe, maybe not.
This is not true. Isn't it obvious that "basically because it wasn't Lisp" is shorthand for "because of a bunch of respects in which it differs from Lisp and Lisp is better"?
Note that the comment you're replying to links to RMS's more complete account of "why you should not use Tcl", which lists a number of respects in which he considers that Tcl is not suitable as an extension language. For instance: "It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow." And: "Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users." (Yes, it is kinda ironic that he said that and then proposed using Scheme. But, as he said at the time, the intention was to have two syntaxes with the same semantics, one of them Lispy and one more conventionally "algebraic".)
RMS also did not say that "Tcl was being developed by an Evil company", nor that that was a reason for discouraging its use. He said: He didn't like Tcl; Sun were trying to get Tcl made the de facto standard extension language; he wanted to make sure that didn't happen. There's no suggestion at all that he wanted to stop it happening because Sun were evil.
http://www.vanderburg.org/OldPages/Tcl/war/0009.html
I can't find where I'd seen it, but RMS certainly wasn't really keen on the idea of a BSD-licensed system becoming popular, either.
http://www.vanderburg.org/OldPages/Tcl/war/0009.html
An excerpt, which (imo) should be quoted more often
"Language designers love to argue about why this language or that language must be better or worse a priori, but none of these arguments really matter a lot. Ultimately all language issues get settled when users vote with their feet. If Tcl makes people more productive then they will use it; when some other language comes along that is better (or if it is here already), then people will switch to that language. This is The Law, and it is good. The Law says to me that Scheme (or any other Lisp dialect) is probably not the "right" language: too many people have voted with their feet over the last 30 years. I encourage all Tcl dis-believers to produce the "right" language(s), make them publically available, and let them be judged according to The Law."
That part is actually not entirely true. Languages have positive network externalities, as well as some very serious lock-in (see: Cobol) and switching costs.