Indeed, often user defined exceptions are checked exceptions, because already so many suitable unchecked exceptions exist for simple programming errors.
However, it's not completely unthinkable that a client uses your code in a bad manner, and this exceptional situation is not fully covered by the standard unchecked exceptions provided by the Java API.
Or maybe the standard unchecked exceptions are too broad, and you need a more specific exception.
The only thing you should consider when you define an exception is: "Should I allow the user to recover from this exception?". If yes, define a checked exception. If no, use an unchecked exception.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Also, note that there are many people (inside and outside of the current Java community) who think checked exceptions were a bad idea. There are a number of other languages developed after Java that took many good ideas from Java (just as Java took many good ideas from its predecessors) but I don't know any other language that uses checked exceptions. (Does anyone else know of one?) Even within Java, there are popular tools and frameworks that make almost everything into a runtime exception. Hibernate and Spring, for example.
So, while the tutorial will tell you Sun's official position on checked exceptions (which may or may not be Oracle's position, but so far they haven't signaled any change)... be aware that you may well find some co-workers who think you should not use checked exceptions at all if you can avoid it. There is no single answer to this - it's a controversial area.