As Nexus said the class was created for SFML, so it is fitted for the coordinate system that SFML.
If you put it into your own coordinate system it obviously won't comply to your system.
The problem is that the naming is not even consistent within SFML itself, due to later introduced features that were not anticipated in the original design (as outlined in my post above).
What is the point of negative dimensions other than making it go the other direction?
It's mainly that. Negative rectangles can be used for flipped texture rectangles -- they are one way of mirroring sprites horizontally/vertically. We would have to look at user code to see whether it's used in other ways, maybe even in logic code.
2 Vectors makes a lot of sense to me and was how I would think of it, even if they get stored as 4 seperate items in the class, the interface for a rectangle would make perfect sense in Vectors.
I don't even think it would make sense to store 4 separate coordinates in the future, it will just add unnecessary conversions. At runtime, nothing changes if 2 coordinates are wrapped in a vector class, after all this is C++ and zero-abstraction overhead.
Would you want to store two vectors like (minX,minY and maxX,maxY) or (position, dimensions)?
Position and size. We had two positions in SFML 1 and moved away from it, mainly because it wasn't intuitive whether the second position was inside the rectangle. Also, I have personally made the experience that position + size are often easier to work with.
For SFML 3, I could imagine the following API. It wouldn't semantically be different from what we have now, just different names and vectors instead of separate coordinates. Instead of rect.left, we would have rect.position.x, while rect.width would be replaced with rect.size.x. The fact that there's a need for vectors is already apparent now, considering the vector constructor and possible getPosition()/getSize() methods.
template <typename T>
struct Rect
{
... // methods
Vector2<T> position;
Vector2<T> size;
};