I don't know. Index-only scans bring a level of feature parity with Oracle. Range types / range exclusion constraints introduce features that no other DBMS has - and solves a messy, hard problem that you pretty much have to hand-code for each scenario.
One of these is legitimately revolutionary, and it isn't covering indexes.
I have to admit that I am not as familiar with this feature, so I will check it out. I glossed over it as something I could already accomplish with a check constraint or a trigger, but I think you might be right that there's more to it than that.
The reason a trigger or check constraint is not enough is race conditions. While the trigger or check constraint looks at the other rows in the table for a colliding range another transaction may at the same time insert a colliding range. The two concurrent transactions inserting ranges wont see each other and both will be inserted.
Without PostgreSQL's exclusion constraints this can be solved in various more or less ugly and problem specific ways. Like locking the entire table, allowing overlapping ranges and cleaning them up later, implementing an own locking infrastructure (e.g. have one lock per day or per room), only having one process inserting at the same time, or just ignoring the problem and hoping you wont get any race conditions.
Exclusion constraints is a clean solution to a messy problem.
One of these is legitimately revolutionary, and it isn't covering indexes.