Misleading is the right word.

Wrong conclusion: E[Earnings|Language=OCaml] > E[Earnings|Language=Javascript]

More accurate conclusion: E[Earnings|Language=OCaml,School=Top10,Major=DualCS/Math] >> E[Earnings|Language=Javascript],

E[Earnings|Language=Javascript] >> E[Earnings|Language=OCaml,School=Who?,Major=Not DualCS/Math]

This can be stated more generally:

If you didn't explicitly control for it, your results probably only reflect selection bias.

I'd say that it is definitely possible for selection bias to indicate a causal relationship though. Because hiring and compensation isn't just controlled by technical ability or productivity. So there is chance a supposedly non-causal indicator will have a direct impact.

For instance, let's a dev with a really unremarkable resume gets paid significantly less than his coworkers in a really hot subfield because all his coworkers have a top-10 stem degree, research with top professors, and work experience at really hot startups. It's likely if he is a decent negotiator the underpaid dev's compensation will eventually revert to the mean. That will be the compensation of an extremely marketable dev if he can sell himself as a dev with really valuable experience.

while it's true that usually, you need to understand the basics of CS to write good functional code, we've often found that that doesn't need to be 100% correct.

we've placed a good amount of functional engineers from a Math, Physics, Logic sometimes even Biology background that had a strong affinity for functions and found OOP generally painful.

I think it's that functional programming is more of a niche with an even more disparity between demand/supply regarding the salaries.

Oh, and usually HR people have a pretty bad filter when it comes to functional engineers, so they only filter by keywords