Making sure that a web application's forms consume the correct values is a big job. It's gets even more difficult when you consider complex and ever changing business logic that often goes into an application.
When PMG builds PHP applications, we rely heavily on Symfony's validator component to help use ensure that our apps take in and use valid values. The most powerful part of the validator component is the ability to create custom validation constraints to help encapsulate that logic.
The real strength of a custom validator is it's name: a custom validator name can instantly convey why it exists and what it does. Symfony's generic validation constraints are amazingly powerful, but they don't really convey any sort of information about the business reasoning for their usage.
This leave us with two possible valid bids: -1 or a number between 0.1 and 100.
to ensure the conditions above is probably to use an Expression constraint.
opaque to the very crucial question of why.
The purpose of the constraint is clear: someone reading this code doesn't need to puzzle out why the expression is what it is like they would have in the first example.
It's reusable — if multiple bid inputs are accepted (like a file upload and along with a web form) the bid validation logic doesn't need to recreated each time.
A custom constraint can provide better error messages about what's wrong with the bid and give the user better feedback.
The bid validation logic is testable on its own without being tied to a specific usage.
Those benefits, especially testing, are huge. Not every set of constraints needs this sort of treatment, but critical and complex parts of an application can definitely benefit from it.