(Note that I’m not familiar with your library, so I may be missing some nuances of your viewpoint.)
While I can understand that view, I have to come down on Enumeratum’s side on this point. It’s an implementation detail if you’re only doing pure Scala. But if you’re doing systems integration, working with other systems that have their own strong opinions about naming conventions, this ability to auto-translate the names looks to be a godsend. (I’ve only picked up Enumeratum this month, so I haven’t used this feature myself yet, but I’ve wanted it many times in the past.) It’s a great boilerplate-reducer.
That said, I can see the argument for separating the name-translation from the identity of the Enumeration itself, to be able to do multiple distinct translations for a given value. (Your QueryStringBindable vs BSONWriter case.) But the completely general Value => String just restates the usual boilerplate – the whole benefit here is automatic translation between the name in code and the external representation, same as is done in many serialization libraries. I wouldn’t want something that generalized, but I could see wanting to be able to define the translation as a subclass or typeclass rather than mixed into the enumeration itself, if that was possible, so that a given enumeration could be expressed differently for different interfaces…