Earlier quoted context omitted.
Agreed, but a lot of code doesn't need to be understood. Knowing which is which is the art right now.
Uhh... what? You'll instantaneously feel very differently when the service you're responsible for is down at 3:15am and your logs are full of stack traces that end somewhere in that code that "doesn't need to be understood". At that point, you will need to understand it well enough to fix it stat.
You can also do this for apps that are just tools for your own use. You satisfy yourself that they are working, and you use them because they save your time. You review enough to be sure its implemented the way you think it is - and if it is working, that tells you quite a lot. Sometimes you will be surprised and have some time wasted.
Yes, yes - there are people who will make the wrong choices in some of these cases but that doesn't mean there are never cases where you can do it.
More broadly - anyone who works in a team is already working with code they don't fully understand. I have code I wrote years ago I don't fully understand. I trust its observable properties and its track record.