I've seen this with CGI. CGI still looks awful somehow, but people about my age think it looks cinematic, and people a decade younger think it looks incredibly realistic.
Haskell hates side effects, but not functional programming. FP has been fine with side effects for decades - even SML, the precursor the Haskell, has them, although forwned upon.
The goal of OOP is also to be modular and composable. I think the thing that is a good design choice is modular and composible. It's what the industrial revolution / assembly line was based on. It's what vim keybindings are based on. Heck, it's what programming languages themselves are based on. Here are some simple tools that do easily understandable things together, now put something together with it. Lego bricks are fun and useful and it's not the domain of any one area of CS.
This is why academic articles (should) contain pseudocode. I do prefer functional concepts illustrated using ML-family syntax over equivalent C-family code because C-style syntax seems to be verbose, full of boilerplate, and just overall not as well suited for expressing functional concepts. I personally find myself doing context-switching where I struggle to incorporate information I learned in a functional context into an imperative context and vice versa.
I'm a strong advocate of pseudocode. I've had a few situations where I explained something online in Python, people complained they didn't know Python and couldn't understand it, so I just sort of arbitrarily change the syntax a bit so its inconsistent, and people reacted much better to it. Throw in a curly bracket and semicolon, maybe an arrow or two, write a line in English sometimes, invent syntax on the fly and then use completely different syntax on the next line. You wound think that would harm comprehension, but actually I've found that it focuses people on what's important and gives them an idea of what to follow along with (the ideas, instead of the syntax which is different from one line to the other).
That said, ADTs and pattern matching I can see needing care to making the article understandable to people on the fringes of your target audience, but if you can't handle functions and recursion, then you're not a programmer with the sufficient expertise to make use of the article in the first place. The target is already functional programmers who know enough about functional programming that stating a problem in purely functional terms is a requirement for the refactoring technique. If you can't state things in terms of first order functions and recursion, then you can't perform the underappreciated tool for which the article is based on.
In conclusion, use pseudocode and imagine your audience is slightly sleep deprived from having a screaming baby at home.
Different people have different expectations for that sort of thing. Sometimes a request isn't and the requester is expecting a certain bend-over-backwards mentality to make the lightest of requests. Other people are blunt and direct to a fault, the exact opposite of that, erm, "spectrum." In either case a manager needs to understand and accept differences between people, because that's kind of their job in most cases. Of course, I'm an introverted programmer, so my empathy tends to lie with the dude that has aspbergers.
Same thing with etymologies: if it has a funny story and not "from the PIE kwa* or possible borrowed during the late 5th century meaning basically the same thing" then it's probably false.
But the only time it is buggy if you SAY it's Linux. If you say it's Windows, it works fine. That's not having the software passively become buggy, that's CHANGING the way the software works if and only if the OS is Linux, but working correctly if it's told (but isn't actually) Windows.
I don't think this is a conspiracy, but I don't think the characterization that users think that because OneDrive works on Windows better than Linux, buggy by inaction is assumed to be buggy by action: this situation is far more damning than that.