There are good reasons for Julia to use its own package manager rather than tethering its fate to Conda. It would be an opinionated and heavyweight dependency, and not everyone thinks that Conda is the bees knees. Being able to drop it is viewed as a considerable advantage by many, particularly since Julia’s package manager is very nicely designed and works well.
Furthermore, Conda is not really intended as a robust multi-language solution. It’s a Python thing which later had R support tacked on. I did my R installation via Conda a few years ago, and when I ran into some weird package installation errors, I came across some advice from Hadley Wickham to install R from the R website instead, because Conda-specific bugs are quite common. Which is what I’ve done ever since.
None of this is specific to Julia. There are a dozens of new programming languages out there, and not one of them has chosen to subordinate itself to Conda. They’re all facing similar considerations, and it’s such a straightforward call that I doubt many have even contemplated it.
My advice is to use tools the way they are used by other people. If you want to learn Rust, use Cargo. If you want to learn Haskell, use Cabal. Trying to fit a tool into an idiosyncratic workflow is a recipe for a lot of work and frustration for very little gain. This is a lesson I have learned the hard way.
If you don’t like that advice and are fully committed to Conda, that’s fine. Python is a big world, and lots of people can get their stuff done without leaving it. But while I can’t speak for the Julia community, I can make a very high-confidence guess that the plea in this thread won’t get a lot of traction. Moving to Conda would have numerous high costs and offer little advantage, since the vast majority of users are fine with learning a new package manager when they learn a new language. And even if they weren’t, only a subset of Python users use Conda, so switching wouldn’t even solve that problem.