Interestingly enough, a professor of organic chemistry[1] created a new Common Lisp implementation[2] just so that, among other things, he can use a very high level functional(ish) language in his research. His CL implementation is specifically designed to allow more seamless interoperability with libraries written in C and C++.

[1] https://drmeister.wordpress.com/about/

[2] https://github.com/clasp-developers/clasp

I think you've basically hit on the reason: chemistry is hard! Organic chemists would get nowhere if they had to do everything from scratch, deducing the behavior of large complicated hydrocarbons by applying quantum mechanics to the individual atoms. Instead they can just say "I know how benzene behaves", "I know that alcohols act this way", etc. Similarly, when coding, it's nice to have a lot of concepts baked into the language in the form you're going to use them in rather than have to reconstruct them from scratch. For instance, Haskell supports something resembling structs with named fields via "optics" (lenses). But it's a lot to wrap your brain around compared to opening a python repl and typing "x.attr".

Haskell supports structs with named fields out of the box in the form of records.

    data Foo = Foo { attr :: Integer, attr2 :: Integer }
    
    printSomeNumbers = do
        let x = Foo { attr = 3, attr2 = 4 }
        print (attr x)
        let y = x { attr = 7 }
        print (attr x)

It's true that the formatting is different, but given the rest of the language that's not really a problem. What is a problem is how ugly nested record updates are:

    data Bar = Bar { attr3 :: Integer, foo :: Foo }

    setTheThing x i = x { foo = (foo x) { attr = i }}
        

That's... not great, is it? And as you get deeper it gets worse, and it can actually get less efficient to as you keep diving down through structures to grab the pieces you need to reconstruct the unchanged parts of your new copy of the record.

So it's not about "x.attr", but "x.attr.field = 7" and friends.

i didn’t say haskell should be used commercially; imo it should not. I say commercial projects would benefit greatly from a study of computational structure and that is equivalent to a study of Haskell (given that it is exactly a catalogue of computational structure). That knowledge can then inform commercial practices.