The notion/mindset that "This tool can only be used if you are good enough" is an enormous design smell in my opinion.
Tooling exist to help you and your team do the required work as good or fast as possible.
If you are using tools to gate keep juniors in your field, or that are unnecessary complex in order to stroke your own ego. Then the tool is more of a weapon against the rest of your organisation instead of something helpful.
About that, I loved that perl could be learned in layers. You learned the basics while using the language, and could discover one layer after another and Perl, mostly, kept you going and behaved as you expected. (By contrast, as I see it, to C++).
Except that no: Many people were not even paying attention to that. And the perl sigil system - which was taught pretty much from the start - was still one of the top objections! It wasn't gatekeeping. It was people refusing to learn the tools they were meant to use.
Have to agree with this one, and also, there is something that I think is easy to forget until you actually face code that has been worked on by dozens of people of completely random backgrounds, over decades: your wisdom doesn't necessarily coincide with someone else's wisdom. Context switching across people - and especially people who barely have anything in common - can be really troublesome. You have to know everything that somebody else you work with has ever used.
Tools aren't all made the same. Some are made equally well for novices and experts, and some require expertise. It's not a "design smell". Haven't you ever used a tool that wasn't made for toddlers?
Tooling exist to help you and your team do the required work as good or fast as possible.
If you are using tools to gate keep juniors in your field, or that are unnecessary complex in order to stroke your own ego. Then the tool is more of a weapon against the rest of your organisation instead of something helpful.