I’ve probably thought more about open source licensing than most people. You can certainly try non-MIT licenses if you want, but there is dangers to engaging in license innovations. Everybody knows what the industry consensus is on how MIT works (which may or may not match what the licenses says exactly, but there is some legal relevance to the common understanding also) and that makes it easy for people to use, contribute to, etc. The key thing I would say is that you have to be clear in your mind on what you want to achieve by the licensing choice, and you have to be sure that the (significant) downsides of going against the bulk of the ecosystem will be worth it.
In particular, you should consider that non-MIT licenses will prevent the code in your package from being incorporated elsewhere in the Julia ecosystem. Now you may say “if that needs to happen, I’ll just relicense it”, but with the standard distributed copyright system, you don’t have that option if you’ve taken contributions. To fix this, you’ll like need some of CLA or additional side agreement that permits such relicensing, but now you’re engaging in full-on license innovation.
Mind you, I’m not saying license innovation is bad. But I am saying that it will cause pain, and you better be sure that the pain is worth it. For example, when I released Cedar, I made a very conscious licensing choice not to license the whole part MIT (though most of it is MIT dual-licensed for precisely the re-use reason). However, I spent many $10k on expensive lawyers to make sure to get this reasonable - it’s easy to screw up, but I thought it was worth it in that case. We’re also very carefully tracking contributor IP rights in case re-licensing becomes ncessary. I’ve never though it to be worth it in any other case, and I’ve written a lot of software.