I find that these sorts of polarizing statements which either side can take to mean a one-up on the other side tend to get lots of upvotes on applicable forums.
I would only take it as hubris or condescension if the language designer chose to write their compiler in a language other than the one they were designing. Otherwise, I'd interpret the presence of strong guard rails as humility, an acknowledge of how fallible our puny human minds are and how much help we need from machines to minimize the cost of our inevitable mistakes.
Alan Kay referred to this as the "Wirth school of non-programming".
It obviously has some merit, but I'd rather have a language be an enabler rather than a disabler. And again, not having to worry about messing up is or at least can be a kind of enabler, but I prefer a more positive approach, with good defaults encouraging me to do the good and simple, but the language getting out of my way for things it might not know about.
Why was it called non-programming? Because it is so concerned with limitations?
IMO, the current zeitgeist seems to be a knee-jerk reaction to a prior idea: "everyone can program (e.g. previous zeitgeist)...but, we need guard rails in tools! Put as many guard rails as we can into tools!" Thus, you have languages prescribing architecture (Elm), web frameworks imposing naming conventions (Rails), etc. At least Rust's limitations help with reasoning, vs seeming capricious.
I'm preaching to the choir here (parent), but Obj-C remains the most interesting language I've seen in a long while: dynamic runtime with a static type-checking for a great majority of code, along with very good performance.
I think you need to start with a limited language in a given paradigm before you use a language that tries to be all things.
Back when I first wanted to learn FP principles, I tried with Scala. It went nowhere. I had a problem, and I didn't know how address it in an FP manner. The language didn't help me by getting in my way when I went down a wrong path, so I never learned the 'right' one for FP.
As a trivial example - I want to iterate, I can use a loop; it doesn't prevent me from using a loop and instead directing me to recursion. In fact, with recursion I get all sorts of terrifying comments about making sure it can be tail call optimized, to use @tailrec to make sure of that, or else I might explode the stack, oh-God-what-is-this-why-would-I-ever-do-this-etc. Meanwhile there is that good ol' friend 'for' waiting for me to help me get things done...
Having used other languages, though, recursion holds no fears. I still am not a fan of Scala, but I'd be okay with being given all the options. Though not for any sort of team development unless everyone else had also been exposed separately to the paradigm we were standardizing on.
Well, I'd like to differentiate between different use cases. Am I exploring an idea on a lazy afternoon or am I one of dozens contributing to a code base older than the millennium in which bugs might cause measurable loss and some top500 exec call our enterprise's exec? I wouldn't think it reasonable to expect that there is one language which suits those (and there are other) needs equally well. I know which language I'll enjoy better and which my co-workers (and potentially my later self) enjoy better. It helps to be paid for using the latter.