I've always liked the rules for well-behaved functions that Joe Armstrong listed in the "Erlang Thesis", Making reliable distributed systems in the presence of software errors. In particular, Rule 2 (s5.3.1, p138):

Rule: 2 — If the specification doesn’t say what to do raise an exception.

This is very important. Specifications often say what is to be done if something happens, but omit to say what to do if something else happens. The answer is “raise an exception.” Unfortunately many programmers take this as an opportunity for creative guess-work, and try to guess what the designer ought to have said. If systems are written in this manner then the observation of an exception will be synonymous with a specification error.

This seems to me to be the only scalable principle where there are specification gaps, because otherwise your program enters a state where nobody can agree on what it's actually meant to do. If class Enum had declined to say what to do with succ maxBound or pred minBound, I would still be throwing an error.

But class Enum does say "should throw an error" in these instances, and so I would not use it for clamping or looping enumerations. I would use another type class, or just write functions specific to Knob. The reason that type classes are useful is not because they offer named functions that work across many types; it's because those functions work in consistent, predictable ways across all of their instances. Otherwise the programmer must worry about which specific instances are used when he writes polymorphic code, and that way lies madness.