As with any piece of advice, there are cases where it applies and cases where it does not apply. Or, in other words, someone can claim "Well, of course!" for the opposite advice.
A [closed, open) interval of calendar dates incidentally does correspond to the number of nights spent. So booking [Jan 13, Jan 14) would mean spending one night. The hotel gives you until, say, 11:00 to get out the next day without paying for that date.
Half-open intervals are neat because they concatenate without overlap.
So [Jan 13, Jan 14) + [Jan 14, Jan 15) = [Jan 13, Jan 15).
This is a very convenient property when dealing with dates in particular, but also indices over arrays.
When I'm booking that stay between Jan 13th and Jan 14th, and I am presented with options, the ones that say "sleeps 2" does not mean [1, 2) but rather [1, 2] and the one that says "sleeps 6" does not mean [1, 6) but rather [1, 6].
When looking for a booking you are using an interval.
When looking at room capacity you are looking for a minimum. This is not the same as an interval. If you are looking for "sleeps 6" that is your bare minimum acceptance in capacity. You are not interested for the [1, 6] interval. Nothing below 6 makes sense.
Even if you wanted to force the interval use here, I'd say you'd be looking for the [6, INF) interval. That is, rooms with capacity of at least 6 (but having more capacity is fine).
For some of them arrival and departure date are most relevant, for others it is arrival and nights (or first and last date of the evening of the night). In the latter case, think of a calendar that shows the occupancy of a room for the manager. The only reasonable way to do this is to mark the days where the room is occupied in the evening and ignore the morning.
With rental cars it is even trickier, because there a 24 hour cycle form pickup time to drop off time is the basis for counting the days of rental.
Some metrics are best made available to managers in two versions for convinience, e.g. trip price per person per day vs. trip price per person per night (where day = night + 1).
For the business logic (except for rental cars, which use a modified one) I implemented a special general purpose Duration class with the following properties:
DateOfArrival
DateOfDeparture
DateFirst /* same as DateOfArrival */
DateLast /* day before DateOfDeparture */
Nights
Days /* Nights plus 1 */ With this class, it is easy to switch between an open and a closed interval view of the same data, and it is very transparent in the source code which is actually used.
But I've bookmarked it, in case I run into someone who thinks they disagree, in which case I can offload the explanation.
I had a similar incident with colleagues who had discovered the "Default" trait and starting adding defaults to everything, including things that didn't have good defaults, and things where they didn't mean default but actually something quite specific such as "empty". The canonical "don't do that!" blog post didn't exist, so I had to create one.