There's a very special reason why these research languages never get adopted.
They usually have a wide range of shortcomings or design gaps that make them unsuitable for real programming. It's usually one or two things that shine. The rest are patched with matchsticks and putty.
This is enough to allure an immature academic, they think that if enough languages with these shining bits are amassed, then they will complement the matchsticks and putty in each other. Not so.
Coming up with a constrained, closed world, greenfield and limited-scope theory is the easy bit. Figuring out how to patch all these ideas together to form a whole is thankless work that academics in general don't appreciate, and thus don't do. This is beyond the average industry practitioner: their knowledge of theory and general theoretical intuition required to conjoin the ideas is insufficient.
It's perceived as an engineering task, while deep down it's something far beyond that. Of course, it wouldn't hurt if academics hadn't seen engineers as cross-eyed and bow-legged - their contribution would have otherwise lead to many interesting things.
