This depends on the richness and complexity of the space you are modeling.
The more your enums look like ānames for integers,ā the less use you will have for bound methods. But consider playing cards: they are frequently used as an example for enums, and there are plenty of questions you might ask about a playing card. Is this a face card, what is the rank, what is the suite, what is the score of this card (depends on the game, obviously)? What nicknames does this card have? What aliases? Does the card have a name or just a descriptor? (Graceās card, the curse of Scotland, a āsuicide kingā, āthe man with the axeā, ālady Luckā)
Or consider file/directory permissions. On āsimpleā unix systems, there is still the umask value to be factored in, so an āeffectiveā value might be quite different from the actual value. In an ACL environment, with cascading settings from higher levels, this may be quite challenging. Is this still the domain of an enum? Thatās an implementation thing. But thereās likely an enum in there somewhere.
Or, what about HTTP request methods? (GET, POST, DELETE, etc.) There is a big collection of attributes around those values - can they be cached, shared, etc. Thereās enough complexity that the answers probably arenāt found in a table. Itās worth writing a function to determine the answers (some of which depend on the individual request). It might not be an enum-level function, but thatās implementorās choice.
Finally, what about enumerated values? Objects that arenāt integers at all, but that we can still meaningfully talk about in shorthand. Toolchain? Gcc vs. clang. Binaries? Elf vs. Dwarf. Boxers or briefs? Paper or plastic? Fight or flight? Craps or Roulette? BMW or Aston-Martin? There are plenty of āthingsā we model with potentially infinitely-many values, but practically only a few. Again, that may be an enum or a tagged enum with an āOtherā option, or something else. But it certainly could be an enum in version 1 of the project, and have lots of operations and queries to interrogate.