Would you go to a doctor who understands how to do a heart transplant, but doesn't understand the Navier-Stokes equations underlying how viscous fluids like blood behave? Would you trust your car to a person who doesn't understand friction at the level of interatomic forces? Would you seriously trust your life to an airline pilot who couldn't single-handedly design and build a plane at least as capable as the Ford Trimotor?
People have always been specialized. Always always always. Even back before "specialization of labor" was officially invented, the people who lived in the Kalahari didn't know about hunting seals and people who lived in Polynesia couldn't hunt a buffalo or a bison to save their lives. There just isn't enough time, interest, or opportunity in one life to learn everything top-to-bottom. We're slowly improving the amount of opportunity, and you can fake an interest for a while, but increasing the amount of time is still a miserably slow process.
The ability of a surgeon to successfully remove an appendix necessarily involves a fair amount of knowledge of the circulatory system, so the analogy is flawed. In my experience some people get by just fine only knowing how to address a problem through some particular framework. The point of abstraction in the end is to release people from the burden of considering the details.
I think that this is a better analogy: would you go to a massage therapist who knows how to release tension in your back by manipulating your tissue, but doesn't know how neurons and axons work? Perhaps greatness can be achieved by a a therapist who knows the ins and outs of every aspect of your body, but as a patient/customer I am really only interested in the skills of the therapist insofar that they manifest in the ability to relax my back and shoulders. And really, a lot of development problems are like that. People perform well at their development jobs without a firm understanding of the mechanisms and inventions that enable them to perform it in the first place. It's by design.
The real problems arise when there is something you really ought to know. For example, if I don't know how memory is allocated by the black box framework I use and memory use suddenly blows up through my interactions with it, the only thing I can fall back on is a lower level understanding. But usually this is fine, and it is someone else's lower level understanding that you fall back on. If you're working high up in a web front-end perhaps you have to consult someone who contributed to a web framework you're using. Maybe you have the wrong approach in a way that leads to instantiating too many objects. On the very low end of software development you may end up having to consult someone who laid the board out and can reason about the operation of the application in terms of the electronics involved. Maybe these two buses shouldn't be used at the same time because of a reflection problem.
You should know one abstraction layer deeper. In this case one abstraction layer would be that the therapist knows what muscles there are in a back and where they are. You can administer massages without knowing it just by memorizing patterns, but you would get a lot better and can handle more cases if you know about the muscles.
Similarly you can become productive using a framework without knowing anything about how the framework works underneath just by memorizing patterns which works, but you would get a lot more productive and can handle more cases if you had a decent understanding how the framework is implemented.
More generally, I'd say that it's a matter of what improves your ability to perform the work you want to perform weighed against the possibly diminishing returns of investing time and energy in understanding things in more and more detail. Depending on the circumstances of your work, this may favor digging into more than a couple of abstraction layers (for example, an embedded developer that knows both software, digital circuit design and electricity can be immensely useful) or it may favor unquestioningly accepting the layer of abstraction you target as the whole truth (for example if I'm working on expressing some performance insensitive business glue logic for some proprietary platform, in which case I don't even have a choice).
The parent's question was if you'd trust an appendix doctor who didn't understand the associated systems.
Which is a brake mechanic who doesn't fully get fluid dynamics, but does get brakes.
I think a better analogy for software would be construction. Multiple people of different specializations and skill-levels working together to produce a single artifact. As a framer, you don't need to know how to lay the foundation, you just need to know how to build on top of it. Furthermore, you don't need to know the chemical process of concrete to pour the foundation, you just follow the recipe that's been proven. You don't need to know the math required to determine the integrity of a structural load in order to frame a roof, you just follow a plan. Some projects may require engineers and specialists who do have a deep understanding of such things, but only to create the blueprints.
So yeah, I'd probably go to a doctor who's really good at removing appendixes over the guy with comprehensive medical knowledge.
An eye specialist who is absolutely clueless about heart or kidney function would be unusual, and not particularly useful. Not only do most drugs have multi-system side-effects, but many conditions affect multiple systems.
So Dr Appendix Removal will almost certainly do all kinds of surgery.
Consultants tend to have a more limited focus, but you don't get to be a consultant without doing a lot of other medicine first. Usually they either work as supervisors/managers, or they're called on to consult/advise and maybe operate on more challenging cases.
So let's rephrase. Do you trust an AI controlled robot specialized in appendix removal (with a very good track record) but zero knowledge of other systems or procedures?