I think the abstraction layers are important, they should not be leaky. You shouldn't have to go up/down the stack. If you can't build what you want with one tool, then choose another tool.
This is appealing, but I think it's important to recognize just how hard that is.
Abstractions by definition lose information. If that information becomes important, to any user, at any time in the tool's lifespan, somebody has to go and claw the thing open to find it.
Picking an abstraction that never leaks essentially means correctly predicting the entire scope of your problem. There are ways to improve on this, good abstractions try to offer contained 'leaks' that you can enable or access if needed, but that still means predicting the set of possible use cases.
(For a code-adjacent example, Excel is popular as an abstraction on an RDBMS, but it's low-level and even Turing complete. Higher-level tools which don't permit arbitrary data association constantly get scrapped or exported down to Excel because they don't cover every interesting relationship, and Excel data semi-regularly gets pushed back down to databases.)
In school, I learned a lot about the wonders of encapsulation, black boxing, and so on. Within a few years out of school, I realized that one of my most valuable skills was being able to move down the stack when those things inevitably break down. When I do have to go and a library's source, and very occasionally find a bug in it, it often feels like something that couldn't realistically have been anticipated.
Breaking abstraction layers will kill productivity. There's one article that gets posted to HN every year but I can't find it atm. It's about how long it would take to do something from scratch. Taking it into the extreme, including growing your own crops. For computers that would be like mining your own silicon in order to build a CPU, so you can build a PC, to build a boot-loader, a OS, a compiler, a web browser. It will take you years to write that "hello world" program. If you find a bug in a compiler, then that's one day of work gone to debug and path it. Same with libraries, having to write pull requests to the libraries will take time away from whatever you where working on.
Leaky abstractions are worse then abstractions. If things are hidden, it will take extra time to dig them out, you could just as well have them all in the open.
Lets say you call for pizza, but you need to know how to bake in order to use their self help service, then that's a leaky abstraction. As high levels of abstractions it's OK to only know the name of the different pizzas. And the baker doesn't need a master in chemistry or engineering to operate the oven. We humans are very good at abstracting things and take most abstraction layers for granted, even though the world around us is very complicated.
Yeah while I think one of the hardest parts if a software developer's job (working at multiple levels of abstraction), that's literally the job. You're translating between the business and the sillicon.
By all means restrict yourself to assembly but yhe rest of us will get more done by using things at convenient levels of abstraction for those specific units.
