In the linked gist, you can see that the setter for value is `_nearestValue`, which is used elsewhere in the code. Its role isn't validation, but value munging based on its other uses.

It's functionally equivalent to
A) keep `_setNewValue`, but have it call `isNumber` and return `INVALID_VALUE`, or
B) replace `_setNewValue` with `_nearestValue` and add `isNumber` as a validator

The distinction is what code calls `isNumber`. If an implementer wants to update Slider to use a different data type for its values, in case A they would need to override `_setNewValue` and `_nearestValue`. In case B they would need to override `_nearestValue` and assign an alternate validator for the value attribute.

So wrt "a situation where you want to have both", it's really a stylistic choice, but uses existing configurations and methods (validator config and `isNumber` method) to make the code more readable where there isn't anything to be gained by consolidating munging and validation into a setter. The munging is used elsewhere sans-validation.

validator is a convenience. It's a nuisance to have to define a method that returns `Y.Attribute.INVALID_VALUE` when boolean methods exist. Boolean methods also have conventional names (e.g. `isFoo`) which make the code easier to read. If only validation is needed, not munging, always use just a validator. If munging is needed, use just a setter unless there is a good reason to use both. The Slider's value attribute is an example where it's on the fence, but IMO the code is a little more readable using both.