Rather than point to any particular language feature or design aspect of the language (which are what originally drew me to Dylan), the thing that keeps me there now is that it is a green field.
If one has newer or different ideas about how things could be done or structured, this can't really be introduced coherently and consistently across a language ecosystem that is already big. I think Node did well at the start in part due to being able to build everything new with non-blocking I/O in mind. That's unlike the use of Twisted in Python which had a number of caveats when working the standard library (and now there are a number of other non-blocking I/O libraries).
The other side is that I do it because I enjoy it and we're building something good.
We do have some good language features (like multiple dispatch as someone else has mentioned), we have some pretty good documentation, our upcoming LLVM compiler back-end is generating good code, we have a good debugging story.
People start languages all the time. I find it best to just pretend that Dylan isn't an old language, but something new that is being created on the grave of Open Dylan. We're working on changes to the type system, the compiler, the libraries, and soon, I'll be starting in on some stuff that takes advantage of our green field status. We just didn't go and start a new language from scratch, but decided to build upon the massive amount of work and design that went into Old-Dylan.
I'm glad to see it. My hobby is programming languages and its amazing how many of the older languages have concepts and constructs superior to modern languages. We keep forgetting things we learned in this profession, and its nice to see someone dusting off the old ruins and rebuilding with an eye to some new understandings.
I was talking with someone else last night that has worked on and with Dylan for the last 20 years or so over dinner.
He commented "I'm sometimes afraid to use Dylan as I don't know if someone will be supporting the compiler." I replied that "I'm afraid to support the compiler sometimes as maybe no one will use it."
That said, I've put some years of effort into it and have been actively maintaining the compiler for a while now. Now I'm building up libraries that I need for my green field project and working on some language changes to support that.
I'm now working on a 2-5 year time frame.
That said, if we got another like-minded hacker out of any attention, I'd fall over from joy. We have so many things that we need help with, especially things like type system work, but also plenty of easier things.
Somewhere in a post from a couple of years ago I read "a vision of a different world: one with the flexibility of Smalltalk, the power of Lisp, while still allowing for compilation to efficient code", but as someone said in a comment to the link of that post in HN these these are already covered (and if not, they have a lot of people working on them) by other more popular (and more friendly imho, from the few examples I had a look to) languages..
So again, why Dylan?
Besides that there is little reason to use Dylan, nowadays.
(But see BruceM's comment about using this Dylan as a foundation for further development.)
It was once developed by Apple to replace Object Pascal and C++ for application and also systems development. But with NeXT bought by Apple that was the role of Objective C and many years later now also for Swift.
This particular version of Dylan was developed by Harlequin - the product name was DylanWorks. Harlequin was bought by Globalgraphics. Globalgraphics used the Postscript raster image processor developed by Harlequin and spun off the LispWorks system into its own company. Years later DylanWorks and even later MLWorks were open sourced. One idea of Harlequin was to develop a range of modern programming languages, implementations for those and development environments: Postscript, Common Lisp, Dylan, ML, ... The implementations were closed source and proprietary. When Apple announced their Dylan, Harlequin hoped to follow a market leader by providing an implementation for platforms Apple would not cover: Unix, Windows, ... Also Harlequin might have hoped to use their Dylan themselves for development of software applications.
But Harlequin in this forms does not exist anymore, DylanWorks has been open sourced and Apple has long ago lost interest in Dylan.
On the positive side: this Dylan is free and open source and interested persons can study and, maybe, use it.
Lisp users might be interested to study the prototyped implementation of Dylan for LispWorks. This implementation was not their shipped product, though.
That particular version is another example of a non-trivial programming language built in Lisp - especially given that it also has a non Lisp-like syntax.