This is very related to a talk I did last year [1]. "Part 2: youtube-dl" starts at 18:21. It dips toes into an analysis about software that fundamentally depends on ongoing human labor to maintain (as compared to, e.g. zlib, which is effectively "done" for all intents and purposes).
More concretely, the additional Deno dependency is quite problematic for my music player, especially after I did all that work to get a static, embeddable CPython built [2].
Ideally for me, yt-dlp would be packaged into something trivially embeddable and sandboxable, such as WebAssembly, calling into external APIs for things like networking[3]. This would reduce the value delivered by the yt-dlp project into pure DRM-defeating computation, leaving concerns such as CLI/GUI to a separate group of maintainers. A different project could choose to fulfill those dependencies with Deno, or Rust, or as in my case, built directly into a music player in Zig.
Of course I don't expect the yt-dlp maintainers to do that. They're doing something for fun, for free, for pride, for self-respect... in any case their goals aren't exactly perfectly aligned with mine, so if I want to benefit from their much appreciated labor, I have to provide the computational environment that they depend on (CPython[4] and Deno).
But yeah, that's now going to be a huge pain in the ass because now I either have to drop support for yt-dlp in my music player, or additionally embed deno, as well as introduce Rust as a build dependency... neither of which I find acceptable. And don't even get me started on Docker.
[1]: https://www.youtube.com/watch?v=SCLrNqc9jdE
[2]: https://github.com/allyourcodebase/cpython
[3]: https://ziglang.org/news/goodbye-cpp/
[4]: https://github.com/yt-dlp/yt-dlp/issues/9674