To be sure, they do program applications that are quite different from what 'bread-and-butter' programmers do, and that might influence their taste in programming language features.
We need languages designed to be used by future generations of programmers in a world where usability and tools come first. The "Manipulate symbols in this arcane syntax and hit F5/Run until it does what you want" experience is fundamentally at fault. Sure we have debuggers and IDEs, but they're more or less tacked on top of core flaws, things that allow for whitespace formatting debates or semicolon religion. My IDE and my VCS should just edit and encode the AST of my language. The compiler and IDE should share the exact same code for indexing and finding symbols in that AST -- the language acting as a library to the IDE so new releases with new features are automatically understood instead of lots of duplicated language for highlighting/completing/searching every language for every IDE. These are just a couple examples of the ways we're currently living in a state of sin.
The standard library of a language should provide access to the parser, so that developers can easily create tools for the language they're using.
You can turn the argument around. As writing a parser is near trivial with parser generator tools, parser APIs are not what is problematic with writing tools.
1) It's not "trivial" -- it's actually a substantial amount of work, especially as the language evolves. How many parsers have you written? Do they have public APIs? Which public APIs to parsers have you used before?
2) It can actually constrain the evolution of the language. IIRC Python has had some non-trivial upgrades that "reinterpret" text with a different parse. If you have to provide parse tree compatibility in addition to text compatibility, that makes changing things harder.
I've noticed that people who have taken a compiler class (often not in C) but haven't worked on "real world" parsers (nearly all written in C/C++) have a very idealized notion of how they behave. Parsers written in C are more often than not tightly coupled to both the lexer and compiler.
People have been saying this for generations. Nobody seems to really believes it enough to step up and try to make it work.
Manipulate symbols in this arcane syntax
The same goes for language designers. I don't think that they have no experience programming, they obviously do. I just don't think that it matters all that much.
Additionally the experience of developing software varies widely. Some use IDEs, some don't, some people use debuggers, others use print statements, some people use profilers, others never have a need to. Even if you have programming experience, your particular experience will be very different from the experience other people have, even developing in the same language.
So no matter how little or much programming experience you have, you can't create a great programming experience based on your experience alone. You need to have an understanding of other programming experiences.
You need to have an understanding of other programming experiences.
Of course PL development isn't the only field that lacks easy empirics. And PL development shouldn't let the perfect be the enemy of the good. It's quite clear that PL features do have positive productivity consequences, with garbage collection being the most clear-cut example.
The interesting question is what do we do the absence of good empirical methods.
There are several valid answers to this question. One of them is to be strongly guided by mathematical beauty and elegance. This is the family of languages that started with Lisp and is today represented most purely by Haskell, Scala, Clojure, Ocaml and F#. The key ideas from this family: garbage collection, higher-order functions, rich types, have been accepted by the programming mainstream.
One wonders if these ideas would have been discovered if John McCarthy had studied the programming experience of working Fortran / Cobol programmers, rather than Church's purely theoretical lambda-calculus.
Further than that, in language design you obviously can't do A/B testing, since the cost would be too high, focus groups are in general fundamentally flawed because you can validate whatever you want and UX studies in language design would be too superficial, unless performed for a long period of time, but then you get to the same problems the scientists have to deal with in studies on nutrition.
So unless you're proposing design by committee, which never worked in language design, you tend to get the best results from one language designer that outlays the foundation based on personal opinions and ideally on the prior work of others and is then helped by the community.
I do understand your point on different styles of programming. However you can't please everybody. For example if you choose for your language to be IDE friendly, you end up with Java. Not sure how many people remember, but one reason for why Java EE has been a complete clusterfuck was the IDE oriented design, as in this belief that an IDE can help with the boilerplate and the wiring. The availability of IDEs is also why XML become popular. Even today Java is not usable without an IDE, because Java's libraries have been designed with IDEs in mind and they are too verbose for your brain to even remember the names of methods, let alone the happy path. Ruby's libraries on the other hand have been designed for expressiveness, for being easy to remember, also to counteract the poor IDE support. Neither approach is superior, but the choice in design was very conscious.
Honestly, I'd reverse it and instead of looking for exceptions, ask which languages the OP was thinking of? I'm sure they exist.