> If they're more worried about NAND gates then not only are they failing in their duties, the industry has failed in providing meaningful abstractions so that smart people aren't bogged down in cruft.
That is the premise isn't it? Most abstractions have significant failings, and when those failings matter you need to understand what's going on a layer or two down.
Maybe that doesn't line up with the label "senior engineer" at your org, but if you don't have somebody who knows what's going on you're going to have problems. If you're lucky, they're just performance and cost issues and your business has high enough margins to not care. In my experience though, orgs are rarely that lucky. It's embarassingly easy to pick up a 100x performance win in expensive enough applications that it was worth the engineering time, and much of the time you'll knock out a swathe of correctness bugs in the process.
A brief recent example: The way some dev was calling into a given black box implied the black box had to manage arbitrary contention with low max latency and zero bugs. Most devs are bad at handling contention without bugs, most devs are bad at bounding latency, and most devs are bad at handling performance of any kind under contended loads. That's not an expectation you want to put on your black box (it _might_ be up to the task, but why chance it?), and thinking just one layer down strongly suggests you should write your application literally any other way. In practice, the other way had 10x less code, was dead simple to prove correct at the application level, and it solved the performance and correctness bugs we were previously surfacing from the black box.
Do you specifically need to know electrons, transistors, OSI 7, and all that? Eh, maybe. You'll probably need to know some particular subset that looks too low-level now though, and it can be hard to predict which subset that'll be.