Some systems, like the Kuali accounting system, use a document-centric approach to business software. You can have a workflow that's much like a traditional paper-based system, so this can make a lot of sense. You can overlay this on top of REST to solve many of the problems that REST has, but then you end up with much of REST being just a fifth wheel.
As for ranges, lately I've been sketching up a hypertext system that has some inspiration from Ted Nelson's Xanadu system. In particular, hyperlinks can be made to and from arbitrary ranges in documents, without touching the documents directly.
You can certainly encode ranges in a URL, so something like
/conference_room_3/time_slot_7,time_slot_12
might be POSTable to
If "N 15 minute slots" are something that you want to either all suceed or all fail at the same time, then what you really have in this concept is another entity/resource to add to your model.
I see the REST services in the article expose some very fine-grained concepts, e.g., existence of patients, doctors, and "slots", i.e., appointments. It appears the REST services can readily let one patient book one slot to see one doctor, but most real-world systems aren't like this. So ...
What's the REST-y way to address this situation then, that's a bit more complex: (a) there are a number of conference rooms; (b) each conference room can be reserved for a contiguous set of 15-minute slots; (c) a client using the REST-y interface wants to fully reserve N 15-minute slots in a particular room, and either completely succeed or completely fail. Is there a REST-y way to do this or would one need to rely on some client-driven pseudo-transaction mechanism? (This is kind of similar to the parent's complaint about needing the "createUser" call.)