I wonder if you mean Tcl is bad, or that the damage is caused by Tcl being powerful and obviating the need for version upgrades of special-purpose software. Or something else.
report_timing -from ... -to ...
However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts.
Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation.
Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
This is all fine and good, but when a vendor can no longer change or fix tooling without running the risk of breaking a large customer's Tcl abomination, the flexibility that it provided is now a problem that's dragging everybody down with it. All of this goes without mentioning that electrical engineers that often get saddled with this aren't very good programmers.
People are excited about SymbiFlow for a reason. The hype in spite of how unlikely it is that it will ever match vendor tooling is a testament to the situation.
Take a look at http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Vid... for an experimental approach to displaying Tcl/Tk applications in a web browser.