Keep in mind that I work in the web world, with small to medium businesses outside of FAANG, so that colors my perspective. But in my career, it's often been a stylistic choice (from me and others) to deliberately emphasize readability and maintainability over than what you might call "efficiency" of code and logic.
That means eschewing things like currying, nested ternaries, deep recursions, etc. in favor of simple, flat switch statements whenever possible, maybe broken out into small pure functions (e.g. isDivisibleBy5() and isDivisibleBy(3)) such that each switch condition could be modularly disabled or swapped in and out, etc. Makes for easier reasoning, unit tests, A/B tests (for users), etc. I think the overall goal is to make each paragraph of code pretty obvious and easy to reason about, without having to click through layers and layers of nested/recursive functions, mutable variables, inherited state, etc.
It's a very deliberate shift away from OOP and huge classes that do everything, in favor of a bunch of micro functions written alongside UI code that looks like declarative PHP. Most often conditionals are used to decide whether to show or hide some UI component based on a var, so that var's lifecycle needs to be simple to reason about. I think a lot of old-school programmers would find that kind of code frankly shitty and terrifying, but it's the normal practice on the web these days, partially as a reflection of how the web frontend world typically works (favoring rapid changes not just in UI code but in underlying frameworks, company priorities, product owners, team makeup, etc... it's all high-churn, low-permanence).
Perhaps that is an idiosyncrasy of the web world, especially in the frontend, where teams are usually made up of less experienced and less formally trained programmers. So the code style adapts to match, becoming more verbose, redundant, and memory-intensive (e.g. rarely do we ever directly mutate something in memory directly, instead copying it to a new var that runs it through a function)... but hopefully more readable, maintainable, and understandable by the next dev to join the team in 6 months. It's a very high turnover field, so being able to quickly get a new member up to speed is more important than writing super efficient code.
Anyway, all that is to say... "programming ability" is not the only consideration. They don't have to be some elite coder to write your basic CRUD app or dashboard UI. Yes, they have to be able to code, but it's easier to teach someone what a modulus is than to try to shape an elite lone-wolf coder into a good team player.
I've spent far more time and energy trying to read, understand, troubleshoot... and then ultimately debug... some mad genius coder's "I am very smart" reimplementation of some common semi-complex pattern, like maybe a hashing function or color conversion system or whatever.
As an admittedly mediocre, self-taught coder (but one with decades of experience), I would typically reach for some popular, well-tested and documented lib for such a use case. But the really good coders that I've met see those situations as a fun challenge and like to write their own implementations that have 90% of the functionality, 3x the performance in quarter of the lines of code... but zero testing and often some edge case bugs. I've had to fix and rewrite a lot of that in my career, usually as the guy who picks up these codebases after the superstar who wrote it has left and moved on to the next startup. So I'm biased against this sort of thinking, instead opting for KISS (keep it simple, stupid) to make my own life and my replacement's life easier.
That's just my perspective though. There are definitely teams and managers who prefer the mad genius lone wolves over run-of-the-mill devs like myself, I just don't particularly like working with them :)