Interesting question. Technically, the examples you mention are in two distinct directions:
Web frontend stuff hasn’t needed any special affordances in packaging, as far as I know. It’s just opaque data files from our perspective, which are valuable for all sorts of purposes. If it ever did, I’d be inclined to say no: JS has various package managers already which solve broadly similar problems to Python tooling. I’m sympathetic to tool fatigue in frontend development, but I don’t think it’s reasonable to ask the Python packaging ecosystem for extra work to avoid the JS ecosystem.
C and C++ (both for data science and GUIs) is a different story, for two reasons. First, the C API and the ease of using extension modules have always been a strength of CPython (the reference implementation and most widely used Python interpreter), and it’s crucial to be able to effectively distribute extension modules. Second, C/C++ doesn’t have a generally accepted standard package manager of its own. Package managers like apt and homebrew aren’t easy to integrate with, because they’re designed to install packages systemwide rather than for a specific environment.
Conda is the exception here. It looks like the holy grail of packaging: a cross-language, cross-platform package manager which knows about environments. The reluctance I’ve seen to use it comes from two angles: the perception that it’s for data science (somewhat self-reinforcing, as general purpose libraries may not be published for conda) and concerns about its tight connection to Anaconda, Inc. I have enough sympathy with this that I think the main Python packaging ecosystem should continue providing a practical alternative, not just point to conda for anything difficult.
I haven’t worked out exactly where the lines should be, but that rationale explains why I think they should be drawn further out in one direction than in another.