As far as I am concerned there is one aspect where I think it is relevant for me, as I compile all software that runs on my machine. If it written in C or in C++, there are good chances that I won't need to compile an horrible chain of dependencies (or most likely, try and fail at compile that chain).
That matters to me, because I try a lot of alternative/niche/toy languages, and if I consider those published within, say, the last ten years, half of them won't even compile. It is a disaster. If it is written in shell + C, I can fix a couple errors easily (if there are more I give up because there is no point in wasting my time on something that claims to be next programming marvel and yet is itself programmed like shit). People want to be fancy and pick up toolchains that are not battle-tested like Autotools+C or CMake+C++, and that's the recipe for pain.
For example, today I tried to compile two languages written in Ada, and I had to give up. A mess. Each time I tried to build an Ada project which wasn't mine, it has been horrible. That's antinomic to the image of Ada (clean and strict to the point of being stiff) but that's my repeated experience with building.
I am not even talking about the anti-feature which is compilers which are written in the very language they aim to compile and do not even provide a bootstrapping minimal compiler written in C or similarly fundamental and widespread language. They're generally very proud of their accomplishment :-/
So yes, a project in C (or C++) offers the best chances of success (for building, which is the point I developed here).
Also, considering toy language, I often want to make a dirty hack to add a missing features. If it is written, say, in Haskell, there is zero chance I can do it. Good old imperative languages like C, Python, Pascal, I have a chance and I have already done it.
There is also the case of all the languages built over the JVM. There are really many. But even when they look good to me, they are limited by the opinionated choices of the JVM, and I don't wanna undergo the multiple programming neuroses of Gosling. Also anything Java based has always been terribly, awfully, painfully, excruciatingly slow on any of my machines; I suppose it not an universal experience, but it has always been mine.
------
> compared to well tested, design, architectured, community engagement, track record, performance and usability.
To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects.
But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading.
Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)