Who recommends that?
In a professional studio, you've got a whole bunch of full-time artists and programmers. If you're only making one game at a time, and you do the art last, then you'd be paying your art team to sit around doing nothing...

For a 1 man team, you don't have to worry about the above, of course.

Unless you are professional modeler and your art is reasonably generic I doubt that you will sell much. Prepackaged game content market is not as big as people may think.
Usually the best suggestion is - focus on what you are best at first. If you are programmer, start with programming + placeholders. If you are modeler start with modeling + some quick prototyping in Unity or some other similar tool.
Once you have reached to certain stage and are confident that your idea works, it will be the time to think how to organize other aspects of game development.

Well obviously if you are the one doing the art, things are different, but the majority of developers cannot produce good artwork (we do "programmer art" instead, i.e. 16x16 sprites that look like a six year old child just discovered MS Paint), and it's better to use that as a placeholder first than to go hunt for/purchase artwork for your game first, because:
- a functional game with crappy art constitutes more satisfactory and tangible progress (to the developer) than a nonfunctional game with beautiful art
- the sprites you choose at first will probably be heavily redesigned throughout the game as you polish the gameplay

It's the same reason why people don't decide on a definitive game name before even starting it - you go with a codename used to refer to "the project", and the actual decision of what to call the release comes in the final stages (and you may even end up actually using the original name - it sometimes is the case, but not always)

Greyboxing is a rapid iteration and cost saving exercise. The artists do produce the grey boxes, they are usually modelled, they're just not textured or very detailed. If you imagine a game level that's something like an office; with greyboxing instead of having desk, chairs, paintings on the walls etc, you'll just have walls, floor, and cubes in place of all the furniture. There's not much modelling to do but the artists can still model things faster than other people can (experience with modelling tools) so they would do the modelling, and what this gives you is a good mock up of what a level could be.

Producing actual assets, with textures, and high detail, is expensive in both time and money, this is why there are usually twice as many artists than programmers on a team. And the worst part is that given that expense, once you have the assets, you are stuck with them. Because there's never a good enough justification for throwing a level that has been fully detailed out, even when the setting ceases to work in the story and the layout ceases to be compatible with the mechanics.

So it's pretty useful for small and large teams; because you can build your assets and levels fast, essentially build large swathes of the game so you can iterate, without having to commit to anything, and without wasted hours down the road trying to make old assets fit a new setting or set of mechanics.

For 2d (platformer) games, I just use squares as placeholders. The green square is the hero, blue squares are enemies, red squares are terrain.

I wouldn't consider using placeholders as recommended, but eh it all depends on what path you wanna take for developing your game.

Have you ever seen someone who wants to learn to program games but "can't get started" because they don't have any art? Those are the people that benefit most from the advice to use simple place-holders and replace it later, and they can get themselves completely stuck with thoughts like "I can't start coding the main character, because I don't have a sprite for him", or "how can I make a Pong clone without a paddle and ball sprite?"

In all likelihood their earliest efforts will be buggy and incomplete -- or at least not their best potential work -- whether they have good art or not, and if they're approaching things sensibly they're developing the projects as a learning experience rather than aiming to sell them anyway. The lack of art is an artificial barrier that prevents them from proceeding with their learning, when in reality all they need is some simple shapes to see that their code is working correctly.

Game making is, it seems to me, a team effort. You can't really, except for the simplest games, do it alone. And coders (look at me!) often make terrible artists because we're more concerned with optimisation than artistic vision. We'd dump the colours if we though we could shave off a microsecond on a tight loop.

Game making is, it seems to me, a team effort. You can't really, except for the simplest games, do it alone. And coders (look at me!) often make terrible artists because we're more concerned with optimisation than artistic vision. We'd dump the colours if we though we could shave off a microsecond on a tight loop.

Interesting vision. Myself I care a lot about art and graphical appearance, but I simply cannot produce any myself. I definitely wouldn't sacrifice an artistic aspect of the game clawing for a couple extra frames per second. I mean, performance is important, but at some point you just need to accept that doing computational work takes time.