Sure, but you've also nuked a developer's ability to easily onboard and understand the codebase with "clever" one liners. Good, maintainable code tends to trend toward lower cognitive load more often than compact solutions.
It's very common to see newcomers or people who've never used Haskell at all mention <$> and friends in this regard. Then someone will say that if you just used do notation explicitly it'd be a lot clearer. And then someone will point out that do notation might look familiar, but semantically it can be spectacularly different from what one might expect from truly imperative languages (e.g., when using the nondeterminism of the list monad). So by encouraging overuse of do notation, you're making the code feel familiar, but you're not actually making it more understandable; if anything, you're making it harder to understand, because you're making it look like something that it's not.
Additionally, while do notation is very generic and broadly powerful, <$> does exactly one thing: it applies a function to a wrapped value, producing a new wrapped value. Once you've used Haskell a fair bit, you very strongly internalize this and tend to immediately understand code involving <$>. If all this code were expanded out to use do notation, you'd have to spend a lot of extra timing reading through the do notation to realize that, oh, this is just a re-implementation of fmap, over and over again.
How exactly is it a limitation that the language has greater expressive power than most?
Haskell does have serious limitations: laziness is a horrible default, modularity is a joke, reasoning about performance is very difficult, and the correctness of most basic abstractions is conditional on the user never ever using a partial function, not even accidentally - or else hilarity ensues.
But functors, applicatives and monads are godsend.
That is definitely a fair analysis. Though I suppose that is a limitation it is not necessarily a severe one, or one that should matter to most people putting code in production.
Haskell in general is extremely unfriendly to novices; but what you lose in accessibility you gain ten fold in maintainability.
Haskell in general requires far, far more upfront problem solving than something like PHP or Javascript. It's easy to take for granted the implicit coercion, smart defaults, overlapping scopes when working in PHP to iteratively work on a problem.
In haskell you are more likely to need a pretty good idea of what the final solution will look like before you even get the code compiling the first time, unlike php/js where you can write one or two lines, check the output, rinse and repeat.
If you can't understand German, would you say that usage of German increases one's cognitive load? No, that would be preposterous. If you need to speak in German, then you hire Germans or people willing to learn the language. Onboarding might be a challenge, but it wouldn't have anything to do with the performance of those that do know German.
I myself speak English as a second language, because I had to learn it in order to do my job. Seeing you're from NYC, there's a high probability that English was imposed on you from birth. Good for you given our profession, but a lingua franca is context sensitive, temporary and English isn't even the second most spoken language.
And do you know what language is more universal than all natural languages and that doesn't change much? Math. And math uses symbols, not English words. And Haskell is much closer to math than all mainstream languages.