No offence (right back at you), but I'm really getting the impression you've never used JavaScript client side, where legacy browser support, bandwidth limitations, graceful degradation and accessibility are major concerns for developers.
Your points have some merit, but also reek somewhat of the pedanticry I've come to expect from career educators, or the lame excuses people come up with to go "This way or not at all" about so many things.
Like namespacing and imports when talking about system objects like Document, Window, Node, and Element. Most of which are of client-side use only so you can't even "import" yet (if you still have to support Interdebt Exploder 11/earlier)... or trying to use the wreck that is typescript... since it tries to turn JavaScript into something it's not at which point go use some other language server-side that already has that functionality.
But again a LOT of determining if these things are of use boils down to what you're using JavaScript for. At this point we REALLY have to start thinking of it as two languages with the same name. Client-side and Server-side. There's a LOT of stuff that only works client side, and there's FAR, FAR MORE stuff you can do server-side that will just get you into deep doo-doo client-side.
... and not just in terms of code quality or clarity, but regarding legal responsibility and accountability.
My "daily bread" the past decade having been going into websites facing both civil and criminal lawsuits over accessibility issues. 8 or 9 years ago the majority of clients I dealt with had nothing more than illegible colour contrasts and crappy use of inaccessible undersized px metric fonts, and of course completing the trifecta of design /FAIL/ were fixed width layouts. Mobile has changed the attitude towards the latter two a good deal, but that's NOT the big issue I'm coming across with so many modern sites.
Instead the problem the past four or five years has been idiotic TRASH like react and vue, and the use of modern scripting features like import, type="module", and so forth with ZERO graceful degradation plan. Hospitals that hire fancy know-nothing scripting fanboys who don't know how to keep it in their pants, and only once the job is "done" and it deploys does it come out that half the damned hospital are still on Geode Powered thin clients limited to IE6 on Windows Mobile IN ROM. Public utilities who scripting off/blocked/unavailable/inapplicable there's no access to the portal and its features, a direct violation of laws like the ADA and UK EQA.
You'd think lawsuits like the ones against Dominos or Beyonce would be a wake-up call, more so as every ambulance chaser starts realizing they can go after companies for failing to meet WCAG minimums... but no, JS fanboys go ridiculously overboard with "JS or GTFO" on the front end.
Hence these "large enterprise projects" that more often than not half their bloody codebases should'nt even EXIST in the first place. I swear I wade into one more client's mess to find 100k of markup, 500k of CSS, and 2 megabytes of scripted junk to deliver 4k of plaintext, and a half dozen content media, I'm gonna puke. SICK TO DEATH of seing multi-megabyte train wrecks spread out over four dozen or more separate files doing the job of 64 to 128k of code in three to five files. See when the GOOD SERVER-SIDE PRACTICE of "one file per class" becomes the IDIOTIC TRAIN WRECK OF CLIENT-SIDE INEPTITUDE of "one file per class".
"Same dance different tune" looks stupid when you're dancing the Charlston to Megadeath's "Symphony of Destruction".
In that way, what makes sense server-side is often utter garbage client-side. Hence why so many "frameworks" that straddle the line -- like React and Vue -- cause far more damage than they actually solve legitimate problems.
When it comes to your counterpoints on CASE vs. IF/ELSE (and possibly vs. Array/Object indexing) these too reek of the "but I'm working on big projects" LAME EXCUSE for bad practices or defense of career educator / career student type pedanticry.
This is evident in some of your MIND-NUMBINGLY DUMBASS statements such as:
>> "Also, less code is a stupid goal. Lines of code don’t cost anything, don’t hurt anything and don’t mean anything."
CLEARLY meaning you don't write client-side scripting. You know, where bandwidth concerns are a legitimate issue that minification barely sidesteps? Where battery use on mobile can piss off visitors?
Though I agree, code clarity should not be sacrificed -- but that's where your claims are utter bunko. If a case through break is any "harder" to maintain than breaking it out into a function (introducing memory thrashing on the stack and the overhead of the call itself to the execution pipe), then there is indeed something VERY wrong architecturally.
Much less inside tight loops such as dealing with JSON based data structures, switch/case is often your best case since again, breaking everything out into separate functions or methods makes the code HARDER to maintain, since you have to go trach down the blasted function. This is why in a LOT of cases callbacks are bloated, inefficient, halfwitted TRASH.
See how most people are using arrow functions and Array.each for proof enough of that. Painfully cryptic hard to read code mostly for "wah wah, eye dunz wunna type teh wurd "function" that is also grossly inefficient since it introduces the overhead of a callback for each and every blasted iteration. 100% herpa-freaking-derp in code structure that people are hopping on the bandwagon of left and right, all for what? People being too stupid to write a "for" loop properly or handle the simplest of scoping?
... and you've never written functions that can accept different variable types for type juggling, such as multi-argument handling? It's one of the powers of JS loose type handling and going "Wah wah, but muh typescript" isn't blowing anyone's skirt up. Also makes me think you've never dealt directly with REAL DOM manipulation or morphic code... or do you really when checking Element.tagName make a function for each and every blasted possibility?
Typescript is another of these things trying to make JavaScript something it's not. I SHOULD like typescript, my first high level language (after learning to hand assemble RCA 1802 machine langauge) was Pascal and I spent near-on a decade writing code in Ada. (I could tell you for whom, but then I'd have to kill you... that's a joke). If anyone knows about strict typecasting it's me, and frankly trying to shoe-horn it into a language where it makes for slower more bloated code client-side is just a waste of time and effort.
... and server side, well... you want that type of functionality what the blue blazes makes people choose JavaScript?
But yes, I do prefer spending more lines of code on clarity, hence why a well formatted switch/case should be point-blank obvious when you've got a dozen or so options and you can't afford the execution overhead of a function call. Such as when working with canvas, trying to sqeeze that last drop of performance inside a requestAnimationFrame, trying to keep latency low on the painfully slow Audio API, when rushing to get a loading animation (boo, hiss, but clients insist) in place before first-paint.
That's not "magic functions" that's normal huffing programming. I dunno, maybe it's because I started in assembler, learned BASIC and realized it was too slow for any real task, then learned Pascal, then Ada and DiBol... and only THEN got into the train wreck of cryptic trash that is C syntax languages, I have a radically different opinion of what clear and comprehensible code is... Though I suspect that's part of why I'm constantly getting praise from people on the clarity of my code on various forums.
It's not about writing "magic one liners" as I'm as vehemently against obfuscated code as you seem to be. It's about writing efficient minimalist code that doesn't introduce the overhead of unnecessary and wasteful structures -- like "functions for nothing".
First damned lessons I learned in programming 40+ years ago. The less code you use, the less there is to break, and the clearer the code you write, the easier it is to fix.
Hence why I'm getting really sick of going into places where the client's existing code is 2 megabytes (MINIFIED) of bloated, poorly written, cryptic, hard to follow train wreck laundry lists of how NOT to write client-side scripting spread out over dozens of seaparate files --- using techniques like those you seem to be advocating -- to either do HTML/CSS' job, or to do 48k (or less, fully pretty formatted with comments) in one file's job.
Really sad when so much of it is stuff that shouldn't even be scripted client side, but you get these derpy half-assed "f**** accessibility" frameworks involved, and all bets are off on the sheer derpitude of the code vomited up by people who have not one lick of business writing a single line of JavaScript.