Dylan was my favorite language back in college. I remember following PG's essays to Lisp, and then Lisp to all the newer dialects like Dylan or Goo. Dylan had it all: a metaobject protocol, generic functions, optional static typing, infix macros. I even got started working on an Eclipse plugin for it, which I ended up shelving after like 3 weeks when I lost interest.
Unfortunately, there are large network effects to programming languages, and the stuff that really makes you productive - libraries and tooling - Dylan just lacked. It wasn't practical to write anything larger than an ICFP contest entry in it. So I went from Dylan to Python, which lacks many of the really cool language features and is a lot slower, but at least comes with so many batteries included that you can whip up a prototype for anything really quickly.
I don't really think it's purely tooling that's the issue. If it were so easy to use Dylan, then the tooling would be easy to write.
I think it's performance.
"Scripting languages" tear compiled languages apart when it comes to iterating. Write a "hello world" web app page in Python and Scala, then see which one takes 30 seconds and about a gig of RAM to actually display in the browser.
On the other hand, if you needed performance scaled across millions of users, you needed C or C++.
The big languages are C and C++ and Fortran (if you need performance), a long laundry list of "scripting" languages, and Java. Java is the only one that actually gets a spot because of its tooling, most other languages only got tooling because people loved the languages.
There's a lot of compiled languages coming out (or re-emerging) these days (Scala, Haskell, Swift, Julia) with funky features that require compilation that don't get you closer to the metal. I suspect that's largely because computers now have the RAM and CPU power to actually make them fun to use.
The combo of C(++) and Python is very strong. A friend of mine works in a research HPC lab (think around 16000 cores); they use Python for the IO and interface glue and C for the heavily parallel science code. It's the best of both worlds.
Dylan is compiled. It was done by the same folks who did CMUCL, which was the original optimizing compiler for dynamic languages, built in the 80s, well-before Strongtalk begat Self begat Hotspot begat V8.
Back when Dylan was being developed, C and C++ compilers produced bloated slow code on home computers. Assembly was the only path for real performance.
We were blessed with choice of having compilers for systems programing for Pascal dialects, Modula-2, Oberon, Basic dialects, Forth...
Somehow along the way the UNIXification of the enterprise brought the wrath of C into these other ecosystems.
Unfortunately, there are large network effects to programming languages, and the stuff that really makes you productive - libraries and tooling - Dylan just lacked. It wasn't practical to write anything larger than an ICFP contest entry in it. So I went from Dylan to Python, which lacks many of the really cool language features and is a lot slower, but at least comes with so many batteries included that you can whip up a prototype for anything really quickly.