I think you wanted to write "niche programming language". I don't know what "niche programming" is. So, I'll answer the question as if it was about the language.
1. In my experience (I both had to learn a language for a job and had to teach a language to the newcomers), for an experienced programmer, learning a new language enough to be productive takes couple months. In the kind of projects I work with, it's typical that a programmer won't be productive for several months anyways due to having to learn about the project's structure.
2. I would prefer to work with people willing to learn something new, or those who already expanded their horizons enough to have experience with better-than-average language. It's a natural filter against people I don't like to work with.
3. Infrastructure created around languages is a doubly-edged sword. On one hand you get free stuff in the form of community-provided libraries, on the other hand, the quality varies a lot and you often have to make uneasy compromises, being held hostage of the third-party bad programming practices. In particular, when it comes to Python, since I've been often responsible for auditing dependencies used in our projects, without a trace of remorse, I can confidently tell you: all Python packages are of poor quality. You are forced to choose the best of the worst, and it hurts a lot to take on another dependency. Erlang has less infrastructure, and in many cases you'll be the master of your own libraries. It takes longer to build, but it has the same effect as with living in your own house vs renting.
4. I don't like working in huge programming shops where it's important to take into account the dynamics of the job market. You may hope to have a company with five or ten good programmers. There's no hope of having a company with thousand of good programmers. In the later scenario, you want to rely on simplified processes and practices to produce something of quality. In the former case you have a chance of just being good. It's similar to SOF army units. You cannot have the entire army being SOF, but SOF will have very different arms, tactics etc.
----
Why not Go?
I'm not necessarily opposed to it. But, my point was to show that something existed for a long time. So, Go isn't a good example of that. Conceptually, Erlang is in some ways closer to Python (being based on a VM rather than compiling to different targets depending on platform). Today, Python drifts more and more towards becoming a Java, so, it also becomes more similar to Go, but in its origins it favored short and interactive development cycle, which is also how Erlang is.
So, I was just looking for an example where a programmer would be able to keep similar workflow, but get a net benefit of using a different environment.
> Erlang has less infrastructure, and in many cases you'll be the master of your own libraries
Which, funny enough, are also going to be of "poor quality" when judged by external observer.
At least with Python packages their pitfalls are known and documented. But I get it, NIH can be very enjoyable.
> In the kind of projects I work with, it's typical that a programmer won't be productive for several months anyways due to having to learn about the project's structure.
I can't help but notice that you're shifting the blame to the type of project to protect your precious tech stack.