When I read this title, I was ready to come out swinging against enums since, as you point out, they're nearly never used in a way that gives them an advantage over, say, string literal unions. But you've described their use case really well!

I'd add a qualification to my answer (try to find, then ask). Try to find the answer first, not because you're at risk of needlessly bothering someone, but because it will build your muscle for finding answers. Even if you don't find the answer, you'll have a better, more carefully qualified question if you spent an hour trying to answer it first. Most questions are not bothersome, and most devs like answering questions =)

In general if you care about performant code, you're going to want to write ugly imperative code. Sarah Groff Hennigh-Palermo has an excellent talk that explores FP vs imperative programming in terms of performance: https://www.thestrangeloop.com/2017/adventures-in-the-vbuffer.html In practice, I've found codebases written in imperative style more difficult to maintain, read, and change (they may appear to be easy to change at first). Codebases written in functional styles are easier to read, harder to write, easier to maintain, and easier to change. There's also typically less code. I've also seen functional codebases over-engineered with unnecessary indirection, but that's not a critique of the style; I just feel like I need to note that FP isn't a panacea. It's definitely easier to write in an imperative style when first wrestling with a problem. I find that I usually write my first draft imperatively and then iterate until I've got a nice functional solution. Functional code at its best reads like a poem that describes the problem it's solving.