Make things as simple as possible, but not simpler. That's the rule I try to go by. Sometimes, it actually makes sense for a class to do what strictly speaking amounts to more than one thing, if those things are related on some common theme. Look at .NET; there are tons of classes that implement a large number of interfaces, each with its own list of required members. A method might end up needing to become somewhat long if it does something complex with a number of intermediate steps which are all interconnected and thus don't lend themselves very well to further refactoring. (Refactoring to keep methods short should ultimately be about readability and maintainability; if the long method is more readable and/or maintainable than a short one, all else equal, I will take the long one any day.)
To only "make classes and methods as small as possible" is, in my opinion, misguided. The real challenge is, as @c_maker points out, to provide good abstractions. Your example of grouping two numbers together is great, for example, if you are working on an implementation of complex numbers arithmetic, or if on a Unix system you need to refer to a user/group context. It makes very little sense if the numbers represent, say, an invoice ID and a product ID to be added to that invoice.