The sandboxing features of Deno also seem to have played a role in that choice. I wouldn't overly trust that as a security layer but it's better than nothing.
To me this is a bit alarming as IIRC most app runtime libraries that also have this in-runtime-only sandboxing approach are moving away from that idea precisely because it is not resistant to attackers exploiting vulnerabilities in the runtime itself, pushing platform developers instead toward process-level system kernel-enforced sandboxing (Docker containers or other Linux cgroups, Windows AppContainer, macOS sandboxing, etc.).
So for example, .NET dropped its Code Access Security and AppDomain features in recent versions, and Java has now done the same with its SecurityManager. Perl still has taint mode but I wonder if it too will eventually go away.
This plus what you mentioned is why I would never trust it to run arbitrary code.
Now in the context of yt-dlp it might fine, google isn't going to target them with exploits. I would still prefer if they didn't continue to propagate "DeNo iS SaFe BeCauSe It HaS sAnDbOxInG" because I've seen projets that were actually executing arbitrary JS rely on it thinking it was safe.
It being a checkbox feature is a weird way to frame it too, because that typically implies you’re just adding a feature to match your competitors, but their main competitors don’t have that feature.
In what ways does it fall short? If there are major gaps, I’d like to know because I’ve been relying on it (for personal projects only myself, but I’ve recommended it to others for commercial projects).
Trusting Deno's sandboxing by itself isn't a great idea. An attacker only has to wait for the next V8 exploit to drop, probably a question of a few months at worse.
Now like I mentioned above it's probably ok in yt-dlp context, Google isn't going to target it with an exploit. It's still important that folks reading this don't takeaway "deno sandbox safe" and use it the next time they need to run user-supplied JS.