No, I actually think that having combinators like that makes sense; it's a perfectly reasonable (and very APLish) design choice to Huffman-code those kinds of operations as combinators. I've worked with Haskell code that makes extensive use of symbolic combinators, and once you get used to a given set, code using them can become much more readable. And using symbol pairs where related operations have related symbols makes even more sense.

I just don't think it makes sense to invent fanciful names for them based entirely on their symbology, rather than their function.

It's your language; you can call things whatever you want. But I've seen many languages that I would like to succeed fail or grow very slowly because they failed to engage well with prospective users. And when you already have a nearly-asymptotic learning curve, why add more to it?