In the provided example it doesn't look very different indeed. But I can change your example a bit to prove a point: imagine that instead if instantiating:
spellChecker = new SpellChecker();
you had to do:
spellChecker = new SpellChecker(x,y,z,a,b,c);
what I'm trying to say is that in case you needed some parameters in order to instantiate SpellChecker then the code of the two classes would become coupled since you'd have to create the parameters: x,y,z,a,b,c (and if they are complexed then you'd have to dig in recursively...). Now, if someone changed the implementation of the constructor in SpellChecker - it would break your class!
Further, SpellChecker might be an interface which is implemented every time by a different class, for example: EnglishSpellChecker, ItalianSpellChecker etc. The code which is implemented in your class shouldn't "care" about which implementation is currently used - all it "needs to know" is that this class implements interface SpellChecker and by that - which methods could be used. By doing this you're maintaining two important characteristics of OOP: encapsulation and polymorphism.
Using DI allows you to concentrate on the task that the current class has to do without the boilerplate that's created from handling cases such as the above (creating parameters a,b,c... in order to use them for the new
call)- which not only loosen the coupling but also makes your code "cleaner" and easier to read and maintain.
Another aspect is that it lets Spring manage the objects (beans) lifecycle - but that's another story ;)