No one was ever literally all-knowing but tech people never used to be as micro-specialist as is common now. In the 90s it was quite normal for one person to understand everything from the hardware and networks up to how to make HTML look pretty.
In the early days of Google they probably did have guys who really did understand it all. But not any more.
The last time I looked, a good CS curriculum still teaches people how a half-adder circuit works, how to write code in assembly, the basics of UDP and TCP, how to build a web app, and fundamental algorithms and data structures.
Additionally, students might do a couple of the following: implement a primitive SQL engine, write a simple compiler, program a robot, add features to a kernel, or study introductory machine learning. These are all common undergraduate electives. You don't need to be polymath to switch from debugging packet dumps to writing CSS.
I'm actually a huge fan of good bootcamps, because some people out there will absolutely love coding, and bootcamps give them a chance. But it's perfectly possible to understand computer architecture and networking protocols and React, and a good university CS curriculum should cover many of those topics at an introductory level.
Anything that involves the physical world went in the engineering degrees - we didn't do circuits, assembly, or programming a robot. Likewise networking I think was an elective, as might have been kernels (though I don't recall that one, and didn't take either of those myself). We did talk about kernels in our systems programming course, but the extent of practical work was things like creating our own malloc and creating a simple shell.
Web apps were in the ITM courses (Information Technology something), which was where people learned specific practical skills and most people doing CS degrees didn't touch - I took one out of curiosity and it was so absurdly low-skill-level: The first assignment was creating mockups for site, then imagine spending the next few months on just HTML and CSS implementing it.
One specific example of the theory-vs-practical-application difference between our CS degrees, we didn't do compilers, we did programming language design. Parsing theory, grammars, and after learning Scheme we used it to implement an interpreter for our own language.
Their CS program had two theory-heavy courses. In the harder of the two, the homework worked out to 10 pages/week of proofs written in LaTeX. Honors students could also take a functional programming course early on, where they usually got to write a metacircular evaluator.
The same CS program also had a software engineering course that required a 5-student team to spend half a term building a group project. (Teams were picked by the professor, for that real-world feel.) This usually required a UI, which meant that we got to learn Motif or web programming or something.
This has always seemed like a sensible way to organize a CS curriculum: Everyone needs to write proofs, and everyone needs to write code. Then you can throw in kernels or networking as electives.
An expert in any field must also be well connected so they know who to call / ask / refer to when they don’t know how to proceed.
The topic of regulating tech is as much about financial management as about algorithms. One needs to understand the costs and revenue streams in detail to devise intelligent regulation. I tend to believe swaths of the tech industry are built on obfuscation of finances and that is where we are losing the expertise in a regulatory context.
Look back on past tech booms and note that engineering work was highly financial in nature (rooted in cost benefit analysis). In the software industry it seems like engineering has hardly anything to do with managing costs. Just ship it, they say, and let the "business people" handle the pesky money part.