It still provides some of the same ergonomics. You can put away the mental cheat-sheet ("1: gold, 2: silver...."). Your IDE can find all uses of BookTypeId.Gold(), rather than textual occurrences of "1". Etc.
The static quality of enums is only one of their features, and sometimes a hindrance, and it good to have other options.
sure, but I can't see how this is supposed to increase discoverability of the API...
I see "here is something that looks like an enum, and its possible values are gold, silver and bronze. But you can also give 10, 42 or any number as a value and it will still work".
I don't mean to be overly critical (clearly this approach has worked well for the author), but I am a bit unsure about the perceived benefits.
The static quality of enums is only one of their features, and sometimes a hindrance, and it good to have other options.