There's indeed some comparison there as (as far as I understand) the current implementation of domain constraints all still works on a single table (one column or multicolumn). But the flexible domains (enforce different domains based on a field's value or expression's result) are pretty cool and the JSON-schema based domains could make some (JSON-related) validation things easier out of the box too (I searched the web, looks like Postgres has support for domains too).
For more complex cases, one could write (or autogenerate) triggers, but that will likely cause performance and maintenance issues... so the other option is to standardize any important data validation & logic into application code - and that part of application code can be stored procedures if it needs to be close to the database.
Edit: Sometimes it's easier to sell the idea of using stored procedures for (data) logic to non-database developers when you call them database APIs instead of stored procedures :-)
For more complex cases, one could write (or autogenerate) triggers, but that will likely cause performance and maintenance issues... so the other option is to standardize any important data validation & logic into application code - and that part of application code can be stored procedures if it needs to be close to the database.
Edit: Sometimes it's easier to sell the idea of using stored procedures for (data) logic to non-database developers when you call them database APIs instead of stored procedures :-)