So, exactly like bioinformatics, then. Trivial tasks are supported by packages of libraries like BioPerl, but all the original research is sui generis, with the attitude in general being that each problem is unique and only results get published, so who cares if the code is a write-only mess as long as it does the one job after which no one will care about it anyway. In such an environment, the "Lisp Curse" already exists anyway, so why not get the benefit of a more powerful and expressive language when you're already paying its cost?
(Granted, Lisp for bioinformatics is never going to become a generally accepted thing. But if you're not releasing code anyway, no one cares what language you write it in...)
This is exactly the kind of attitude that projects like 'Software Carpentry' (https://software-carpentry.org) are pushing back against.
The syntax referred to is S-expressions. They are a simple and elegant way of writing trees. Lisp was originally supposed to have M-expressions which would be more like mathematical notation, but it was found that Lips users actually liked S-expressions.
The reason becomes obvious after some amount of Lisp exposure. S-expressions are so simple that before long one does not even see them any more. The parentheses give way and one can just look straight at the Lisp code itself. For this reason many Lisp programmers do not even edit the S-expressions. They instead use something like paredit to edit the underlying tree directly.
It's similar to how readers don't really "see" the letters that make up a word in many natural languages. And, further, they don't see the words that make up certain expressions. We have this fantastic ability to internalise language but so many are choosing not to use it when it comes to programming.
That is the same with most things, we say the verb before the object(s).
I agree that the concepts behind S-expressions are simple and logical, but expressing an entire program using S-expressions is an additional thing that must be learned. Other languages chose a syntax that is closer to what people are used to and that helps with the adoption of the language, even if the language loses other capabilities.
On the other hand, I have taught courses at the high school level at the same school based on "How to Design Programs" [1] using the Racket language. Although I can explain the concept of (+ 6 (* 1 0) (/ -2 2)) rather easily, the students make mistakes writing expressions for several weeks.
Plus when you're used to trees, linearization and parsing, you *fix the way you see fit, pre post or in ...
I've used XLispStat, S-PLUS (a commercial version or R), and SAS. SAS had the most comprehensive statistical libraries, but I never liked the language. I liked xlispstat but the statistical libraries weren't as good as those of SAS or S-PLUS. For data mining, I settled for S-PLUS, which was sufficiently lispy, and had a REPL. So it wasn't just the syntax (or lack of it).
Beyond being dynamically typed and having a REPL, Python isn't particularly Lispy: it's less functional, and it has no (linked) lists or symbols. It's quicker to develop in than most of the non-Lisp alternatives, though.
Furthermore, the disconnect with traditional mathematical syntax has also turned off many users. There was a predecessor to R called Lisp-Stat [2] which never achieved the acceptance that S/R did, and the Lisp-based syntax of Lisp-Stat was cited as one of the reasons.
Following the example of a high-profile Lisp supporter like Peter Norvig who accepted Python as a "Lispy" alternative early on, I think there are a lot of us who have come to accept Python as a necessary compromise. While Python is not homoiconic, functional programming is encouraged through its libraries rather than its core language definition, and the power of macros are missing, the inherent popularity and all the benefits that come with it is tough to beat.
[1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
[2] http://homepage.divms.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.ht...