> If you really do need to change an array, how do you do it in Haskell? ...It's like someone really wants to implement bubblesort in Haskell but instead the solution ends up being to implement quicksort because the bubbling is difficult.

You nailed it! As a math major myself, I completely empathize with this pov. The vast majority of languages present themselves as minor tools that can be used to solve your problem. The goal is to solve your problem, not figure out the tool. If I want to decompose a matrix via cholesky or schur or QR or LU or what have you, I just want to be able to set arrays willy-nilly without thinking so much about how to accomplish the same thing without setting the array. The Haskell way of "let's not really set the array, it's not what you want" which a bunch of comments have expressed here, focuses the attention on the tool, not my problem at hand. I honestly don't give 2 shits about your tool, whether you call it C or python or octave. I care about my problem, not your tool. So your tool should just stand aside, let me do my thing & not complain. That's exactly why the vast majority of applied researchers in math stick to matlab/octave or ml researchers to python or vision/robotics guys to c++ or insert your speciality here...
In each case, the tool is one tiny minor part of the problem solving process. As a quant,I would worry about convergence of pde's and getting the term structure right - yes the whole thing is in c++ but I don't spend days and nights thinking about what does c++ want, I just care about the math. With Haskell, I do have to stop what I am doing and focus on the tool. The language says, lets think about a nice function composition that elegantly yields this transform without dirty mutation. I know such a transform exists,but looking for it is not my day job. Most applied math & applied ml work is seriously messy and highly imperative, for which such elegance is a mismatch, because of time constraints imposed by capitalism. If we were all working with plenty of free time, yes I could concoct the perfect elegant transform every single time, but I don't have that kind of luxury. Haskellers who advocate pausing a bit and rethinking the problem, solving a different problem instead, or expressing the computation recursively with function transforms etc. to suit their language are perfectly honest and right - it's just that I don't have the fucking time to do those things. So yeah, the language is great, but I don't get paid enough to rethink every dirty thing I do with these dirty imperative languages so that it becomes a neat elegant exercise I can marvel at. There is honestly not enough time in the world or money to compensate for the amount of time it would take to rework all the dirty mutable spaghetti that constitutes the majority of day to day work. We all try, but outside of textbook examples and a few select domains, nice fp doesn't scale. It's not a language issue. It's just the times we live in.

It's all quite sad, because when I was in school, I actually led a talk using John Hughes' famous fp advocacy paper, where I expanded his examples into finmath, but once you work in industry and see the frantic pace and general messiness of the code base, you realize even the second coming of Jesus Christ won't get us anywhere.