Just like a huge portion of professional software developers have no interest in learning RTL or digital logic just to program an FPGA.
HLS is a massively complex system to solve this problem. People will also build massively complex systems to solve the problem of "No FP here, please".
Which is why I stand by what I said: this knowledge is not optional, and engineers not willing to learn them are going to be stuck with sub-optimal tools, dragging the whole industry down with them. While I can't be confident this is the definitive solution, I believe that the best way to move forward is to start treating basic FP (purity, data transformation pipelines, immutability, favoring data structures over code) as a baseline that everyone needs to know to work as a developer, and stop treating it as if it is on a superior level of difficulty compared to learning whatever bullshit combination of half-templated server side rendering, 4D DOMs and incantations needed to upgrade Webpack we need to know to be "up to speed" nowadays.
Eh. I'm not saying one way or the other that FP is good or bad, but the software industry is incredibly young and changes a lot. Even in a relatively short period - 10 years, let's say - things are pretty difference. 20 years, still a short time, and things are radically different.
And on top of that, it is still the case that a lot of stuff takes a long time to get adopted. It's hard to build and popularize a programming language, regardless of how good or bad that language is, because they tend to lack interoperability with other languages if they're very different, which is usually a requirement if they want to be considered worth looking at.
So I'd just as easily buy that people haven't used a lot of FP due to inertia, a lack of the right external inventives, etc, and not by any virtue of the paradigm.
Ideally languages prevent bug classes like null deref, use after free while still being familiar enough for most programmers to use.
It's analogous to the spectrum of SQL knowledge folks have. For instance knowing what a group by does vs how a group by reshuffles data on a single node / across nodes. Ideally the language design hides the hard details.
A very tall order admittedly.
After that, https://fsharpforfunandprofit.com/series/why-use-fsharp/ and pretty much anything made by Scott Wlaschin is very accessible, and to the point.
In practice you can write imperative code using either of them but the focus on immutable data structures, and (in Rust more than Scala) functional error handling means that many manipulations are easier to do with FP constructs, so they appear quite naturally (Option, Result/Try, iterator maps etc.)
As a bonus IME they are very similar in many respects so experience in one translates well to the other.
I'm a backend developer by trade and Elm made me fall in love with frontend development, which I've rather hated before.
All problem domains that involve declarative programming, such as configuration (Terraform, Kubernetes, Nix, many build systems), dynamic HTML, relational databases, and pretty much anything that is manipulating data in a pipeline fits functional programming like a glove and is hard to get right in a strictly traditionally imperative fashion. As an industry we should stop pretending FP isn't a necessary part of a professional programmer's education and that we can solve the problem by coming up with the umpteenth "we promise it's not FP" abstraction with its own take on fooling developers into writing functional code through an imperative-looking layer full of foot guns that subtly break imperative developer expectations, like React.