Ob es bei DIESEM IOTools auch so ist, weiß ich nicht, aber: Etliche Unis/Tutorials etc. hatten vor etlichen Jahren mal solche Utility-Klassen erstellt. Der Grund dafür ist einfach: Bis vor Java 1.5 waren Konsolenein- und -ausgabe ein ziemlicher Krampf. Man mußte sich mit irgendwelchen Streams und Readern und Writern und IOExceptions rumschlagen, obwohl man doch „nur mal schnell eine Zahl eintippen“ können sollte. So gesehen mach(t)en diese Utilities schon Sinn, um sich auf’s wesentliche beschränken zu können. Mit Java 1.5 kam aber der „Scanner“ zur Standard-API, und seitdem braucht man solche Klassen (zumindest für Konsoleneingaben und so) eigentlich nicht mehr. Die Tutorials/Bücher etc. wurden dann aber nicht unbedingt angepasst. Es ist ja nicht so „wichtig“…
… und das führt auch zu deinem anderen Punkt: Wenn in dem Buch immer diese IOTools verwendet werden, ist das nicht unbedingt schlimm. In dem Buch geht es ja (vermutlich eben gerade) NICHT um die IOTools, sondern um Java. Und dort wird auch das (legitime) Ziel verfolgt, dass man „mal schnell was eingeben“ kann. Die „wichtigen“ Sachen (Schleifen, Variablen, Klassen, … ) sind ja unabhängig davon. Du kannst dann einfach akzeptieren: Gut, hier rufe ich „IOTools.readInt“ auf, das könnte ich auch mit dem „Scanner“ machen - ist wurscht 
Wo es etwas heikler werden kann, ist, wenn diese IOTools wirklich „mächtig“ werden - wenn sie z.B. einen „Ersatz für Swing“ bereitstellen, mit dem man z.B. Zeichnen kann, der aber mit „echtem“ Swing nichts mehr zu tun hat. Aber das scheint hier nicht der Fall zu sein.
(EDIT: Hoppala, hätte mal reloaden sollen - einiges zum „historischen Hintergrund“ hatte Lex jetzt schon gesagt. Ich finde aber (ganz subjektiv) dass es für das, worum es in den Lerneinheiten gehen sollte, nicht so wichtig sein sollte, ob man nun „IOTools.readInt“ schreibt oder „scanner.readInt“…beides sind nur wrapper für komplexere, „unbequemere“ Sachen. Hauptsache man kommt an seinen heißbegehrten int ran :D)