The best write up I ever heard for this approach (often called "primitive obsession" - http://sourcemaking.com/refactoring/primitive-obsession) was in Object Calisthenics, an essay by Jeff Bay in The Thoughtworks Anthology (http://www.amazon.co.uk/The-ThoughtWorks-Anthology-Technolog...):

"an int on its own is just a scalar, so it has no meaning. When a method takes an int as a parameter, the method name needs to do all of the work of expressing the intent. If the same method takes an Hour as a parameter, it’s much easier to see what’s going on. Small objects like this can make programs more maintainable, since it isn’t possible to pass a Year to a method that takes an Hour parameter. With a primitive variable the compiler can’t help you write semantically correct programs. With an object, even a small one, you are giving both the compiler and the programmer additional info about what the value is and why it is being used.

Small objects like Hour or Money also give us an obvious place to put behavior that would otherwise have been littered around other classes."