Modeling your problem as FizzBuzz is a good way to model an unrealistically simple problem. FizzBuzz itself is only meant to filter out the vast masses of applicants who are struggling to find anything in the job market and therefore apply to any job they see hoping that someone will recognize them and take pity on them. It's not a realistic starting point.
Alan Kay's words are really insightful on this matter; he says that "the right perspective is worth 80 points of IQ." If you can figure out the right way to look at the problem (the right generic problem to solve given your specific constraints) then it's like being much smarter than any ordinary programmer really is.
He gives a much more instructive example: the Windows operating system. This thing is millions of lines of code, so much that if you printed it out in textbooks it'd stretch to the top of the Empire State Building. This was produced by a bunch of people doing exactly what Tom Dalling is suggesting: work only on your specific subproblem, do not solve the generic problems of "how do I make an operating system?", etc. There's no intrinsic reason that a graphical operating system needs to be so big that nobody can read it in a lifetime.
And the bugs that exist in Windows are undebuggable. With that many different components at play in the greater ecosystem, knowing which two are interacting to cause the problems that plague you requires an unbelievable amount of insight into what the computer is doing when it performs those quirks.
I agree with the specific point that software bloat sucks; I'm working with Ext.JS right now and boy is it bloated with internal abstractions that don't make much sense. Fortunately they isolate other people from dealing with those abstractions, but if I were at Sencha developing on the product I'd constantly be wondering "why do we make an 'Operation object' for the thing that the user wants to do? What's the real point of that?" etc.