Why?

I'd guess it's because that's what C++ does. Though it's unclear to me that C++-style iteration (where you increment a running pointer until you reach an EOI pointer) is much used in C.

Storing two pointers into the same array is a memory safety problem. It's hard to implement a borrow checker when there are two live mutable pointers into the same memory object.

I would expect the borrow checker to treat a slice as a logical pointer to all elements that are addressable through it, regardless of how it's implemented under the hood.

This pattern originated in C; C++ iterators were specifically designed to fit it when it was already established.

I've never heard of a good argument for this as compared to a capacity, length, and data struct.

If you have a start and end pointer and you move either one, you don't know what the original size of the allocation was.

D doesn't store capacity in each slice. This allows a slice to fit in registers more often. Instead for GC allocated slices, the GC will store metadata before the first element of the allocation. That does make it slower to access, particularly when the slice points past the first element, but it is cached to speed up repeated accesses to the same allocation. Repeated appending can be further speeded up by using a dedicated Appender type.