There are two equally plausible ways to identify positions in a list/string/whatever. One is to number the elements, the other to number the gaps between them. I'll try my hand at some ASCII art... be sure to view this in a monospaced font.
[ 0 , 1 , 2 , 3 , 4 , 5 , 6 ]
| | | | | | | |
0 1 2 3 4 5 6 7
-7 -6 -5 -4 -3 -2 -1 (0)
When you ask for the slice from 2 to 5, you get the elements between those slot markers. That's [2,3,4].
When you ask for negative indices, the same applies, only there's no parallel way to ask for negative 0 aka end of list. 
[2, 3, 4]
There are a number of reasons for working this way. For instance, the length of the range a[x:y] is simply y-x, negative indices aside. It's even more significant when you look at something that doesn't have
discrete units - such as times. Suppose you invent a data type to represent a time range. You might
describe a TV show as lasting from 10:00 till 10:30; but what do you really mean by those times? Do you mean from the start of 10:00 until the end of 10:30? When is the end of 10:30? Is it the end of the
minute 10:30, the end of the second 10:30:00, the end of the millisecond 10:30:00.000? Easier to describe it as the beginning of that moment, because that has the same meaning regardless of your
resolution. You can always add more trailing zeroes to either the start time or the end time, without changing the meaning of the range.
Same applies to generation of random numbers. If you have a function that generates a random number uniformly in the range [0,1) - that is, including 0 but not including 1 - and you multiply it by an integer
and truncate the decimal, you get a random integer uniformly in the range [0,x), which is an extremely useful thing. You don't even need to care what the actual range in the RNG is (does it produce 0.000
through 0.999, or 0.000000 through 0.999999?), as long as it's significantly more than your target range. But if the RNG could return 1.0, then you need to deal with that possibility in your result, which
frankly isn't much use.
It takes some getting used to, perhaps, given that most people in the real world work with closed ranges; but ultimately it makes far more sense. And if it weren't for a huge case of lock-in, I would wish we
could change the way Scripture references are interpreted, for the same reasons. Taking examples from tomorrow's church service, two of the readings are Matthew 18:15-20 and Philippians 3:8-10. When you
look in a Bible, you'll find verse numbers preceding the verses (at least, that's the convention in most editions). If the ranges were written as half-open (eg Matt 18:15-21), it would be simply from verse
marker 15 to verse marker 21; and "to the end of the chapter" or "to the end of the book" would have obvious notations (eg Matt 18:15-19:1 or Matt 27-Mark 1). Of course, this would make for a huge amount of confusion, since the present system has been around for centuries... but it would make more sense, so I'm very much glad it's the way Python chose to do it :)
 You can use None or omit the index, but there's no "negative 0" integer to use.