First, separate the issue of short code from readable code. While brevity can contribute to readability, it doesn't guarantee it. Nor does it guarantee efficiency of execution.
So I was wondering if it truly matters when code is short and readable
and my enthusiasm about Python and Haskell is justified because there
are lots of situations (in professional software development) were you
see code only from the outside.
Every developer wears two hats: a writer of code and a consumer of other programmer's code.
As a consumer of code, I don't care what language the code I import is written in, nor do I care what coding standards they enforce. I only care that I can call it from whatever language I'm working in, that the code meets my requirements, is correct, and is actively maintained.
However, as a writer of code, I've worked on projects that have had multiple releases over a period of decades. Thousands of other developers consume our code. One of the disciplines that makes this possible, is that my colleagues and I do care about whether our code is readable. Every day I have to revise code that I or someone else on my team wrote 7 years ago.
If you are writing throw away scripts that are used once and never touched again, you might think that readability is unimportant. You'd be wrong, because all but the most trivial scripts have to be debugged to get them working correctly. Debugging readable code is much easier than debugging obscure code.
As an example, if you use the SciPy package in Python you'll probably be calling functions that in turn call functions from Basic Linear Algebra Subprograms (BLAS), a library of matrix manipulation routines written in FORTRAN. As a user of SciPy, I really don't care what their readability standards are. But the folks who are responsible for maintaining BLAS have to care deeply how readable their code is, because they're the ones who have had to maintain that code for almost 40 years.
Now I know a lot of developers do not comment their code. In these
cases you do benefit from short readable code. However as long there
is the opportunity to document code I am not convinced.
Because inevitably the code and the comments will get out of synch, i.e. somebody will make a change to the code and neglect to update the comments. Then the future maintainers will have to figure out both the comments and the code, and figure out whether the comments, the code, or neither, is the correct version of what should be happening. I do use comments, and I try to be disciplined about updating them, but I assure you that even with the best of intentions, they will come to diverge. If your code isn't readable, sorting things out will be needlessly painful.