Point taken, and I agree.
> vector/array
Those two, yes (and vectors really only apply -as such- in C++), but the rest? It depends (the best answer to every conundrum).
I write consumer/developer software; not ML or Big Data Mining stuff. My work is generally in device control, user interface, SDKs, APIs, etc.
That means, that, in over thirty years of writing software, I have encountered exactly 0.000000 binary trees. BTW: Binary trees and linked lists can be an issue in parallel-type programming. We had some image processing algorithms we did that used similar structures, and we had to be very careful. We often had to back out optimizations.
Writing consumer software has issues that don't seem to occur to folks writing engine software. These are things like localization, security, adaptive user interfaces, aesthetic design, information architecture (hoo-boy), responsive controls, branding, testing (all kinds of testing), etc.
That "information architecture" one is a big deal, and almost everyone falls down on it. This is most obvious in settings. Engineers design settings to match the underlying architecture, and don't worry too much about how they will be perceived by users. The result is the infamous "Find the hidden setting" game. I just went through that, yesterday, helping a friend set up a Zoom meeting. Fun! I also just went through it yesterday with my wife, and her Mac. Apple has started to segregate settings the same way, and there be dragonnes.
Testing is another big one. Everyone is fixated on automatic testing and unit tests. If a project comes with a bunch of unit tests, then everyone thinks it's "high quality."
There's issues with relying on unit tests alone. I write about that here: https://medium.com/chrismarshallny/testing-harness-vs-unit-4...
Also, if we write device control, or a lot of communication software, unit tests can be worse than useless. Usability and accessibility testing are also something that can't really be automated.
Shipping software is really boring. There's a lot of "'snot mah chob, man!" stuff involved, that, nonetheless, needs to be done by someone, or we end up with steaming piles of crap.
Some of that involves the programmers directly. For example, do we habitually autodoc document our method headers and class/struct definitions? Do we use tokens and localizedVariant calls for all displayed text? Do we follow good secure programming practices from the start? How would a blackhat use this function I just wrote? Do we throw dependencies in as a first resort? Is that good, or bad? Do we know what that dependency we just committed the company to does? What's our testing strategy? How will we integrate this, and when? etc.
Also, power usage. That's a big one, if we do mobile or embedded software. Sometimes, highly optimized code is the worst code to run, as it can drain the battery, or end up with really strange race conditions between chipsets.
That's practical stuff. When you're a one-man shop, like me, you get to deal with all of it. I was also quite involved in all of it in my last job, where we were a huge, global team, supporting some pretty intense hardware products.