That's not what it is. What it is is this: on Unix-like systems, the chief safety mechanism at every level is operator knowledge. This is in part due to incidental history that many distros (including Pop!_OS) have good reasons to want to overcome. But it's also because they're systems that are designed to trust their operators, and to be scriptable.
This reliance on operator knowledge is present in a negative way (e.g., there's no confirmation dialog or trash system for running `rm` against a normal file). But it's also there in a positive one: programs report to you what they're going to do and provide you with tools to further inspect those reports.
Lots of Linux distros encode these safety mechanisms socially, or through their installation procedures. Distros that don't come with desktop environments help ensure that their users know which packages relate to their desktop environments and how by having the users install those packages themselves. This is famously true of Arch and Gentoo, but it's also true of Debian, on which Pop!_OS and its package management tools are currently based.
It's not a bug that every package you install with apt is related to every other in a uniform way, and managed in a uniform way with all the others. It's a feature, and an awesome one that developers should appreciate and enjoy rather than fear. But it also means that when you use apt to install anything, you're administering your whole operating system, and you need to act like it. That doesn't mean that you have to be extremely cautious, but it does mean that you can't be totally inattentive to dire and emphatic warnings.
If some distro wants to take on young users who can't read, or end users who think 'because I'm just installing an app, I don't have to think about anything the UI presents to me', it will be fighting an uphill battle as long as it tells users to 'install apps' via system administration tools that negotiate a global shared state, with maximal resource sharing, among every program and library installed on the system. And when they do put up more gates, three things will happen:
1. They will become a distro that many users outgrow after trying, because managing and customizing the distro will become annoying to them
2. They will become less and less attractive to users familiar with upstream and other traditional users for the same reasons
3. They will reinforce the same blindness to text, to warnings, and to the transparency of the operating system that these gates were set up to solve.
One of the results of these things is that the distro will increasingly become one used exclusively as a commodity, and predominantly by newbies or others who don't care to know what they're doing. (This could be a good thing, depending on the distro's goals.)
But there's a better way! If a newbie-friendly distro wants to present users with tools for installing applications (i.e., not operating system components) that are more or less safe to use thoughtlessly, they can direct users to package management schemes that don't involve resolving dependencies globally, or rely on the base system, like Guix and Flatpak.
And then they can even leave the system administration tools in place with, yes, some UX improvements (colored text, more concise output, requiring more explicit flags for potentially disruptive or deeply transformative operations), but without turning them into tools that think they know better than their users.
It's in this sense that Linus' experience doesn't indicate a fundamental problem with apt, or a reason that someone who is (willing to become) competent to administer an OS which is hesitant to overrule them should shy away from desktop Linux.
Obviously, Pop!_OS' goals are not aligned with Linus' experience. But that's more because apt was not the kind of tool Linus expected than because there's something fundamentally wrong with apt, or that Linux distros don't still need a tool that plays basically the same role in basically the same way.