Because of how IntervalSets calculates a “duration”, I went into a short rabbit hole of why aren’t all the types of Dates considered as subtypes of Integers (see here for the instigator).
The main reason is that periods are integers in Dates (ironically I once tried to push for float-based dates… long story short I was wrong), and we might as well have them behave like ones…
Any particular reason they’re not…?
Periods are spans between Dates/DateTimes. They are no more integers than are Chars. If you subtract two Dates you will get a number of Days. If you subtract two DateTimes you get a number of Milliseconds. Which would be your Integer? What about the other?
If you want to strip the type and isolate the corresponding Int64,
daycount = date1 - date2; intvalue = daycount.value
(which corresponds to width in IntervalSets, add 1 to get what corresponds to duration in IntervalSets)
Sorry for the confusion: I’m not talking about treating intervals as integers or as dates. Because IntervalSets.duration currently applies only to intervals who’s end-points are integer-like, and has a specific method for an interval who’s end-points are a Date(), I thought subtypes of Dates (e.g. Date, DateTime, Day, Second, Hour, Millisecond, etc) should be subtypes of Integer.
They shouldn’t :). They do not conform to the Integer API: consider
Date("2019-04-24") * Date("2019-04-25"), Day(5)^Year(3)
OK, fair enough, letting it go 
Thanks!
Superfluously, let me add that the reasoning “it is represented as an integer, so why is it not an integer subtype” is the exact opposite of what a type system is for.
After all, every single data type in your computer is represented the same kind of data: bits and bytes. The job of the type system is to overlay meaning on top of this representation.