Ah, no, you don't really mean that (I hope). For example, the real world doesn't do turtle graphics; they make you figure out the Cartesian (but with the Y axis upside down) coordinates of the endpoints of the line segment you want to draw. Sprites, costumes, all those things are abstractions built on top of real world capabilities.
The question is, what abstractions make it easiest for a learner to express their goals with a minimum of arcane incantations.
Actually, even the real world uses abstractions. For example, take crayons. The real world uses crayons! You can say "color:powderblue" and get b0e0e6. And my color library includes the X11 crayons as an option, although I like my crayon selection better because it's more evenly distributed through color space. (They have 20-odd off-white colors, for example: ghostwhite, oldlace, snow, ivory... They probably started by looking at a sampler of house paints.) Even more important, my crayon block has a two-level menu in which the colors are divided into their spectral families, so you don't have to search for the color you want.
But also, much of the time people don't care about the exact colors; they just want to be able to say change color by 1 and get a more or less continuous gradation of interesting colors. That was a good abstraction in Scratch, which they've moved away from by making the HSV scales explicit. (The old way did have the misfeature of getting trapped in black.) My default color scale restores the one-dimensional scheme while avoiding the black hole and including shades of the spectral colors.
Now, there's plenty of room for argument about whether the abstractions I've chosen are the best possible. But certainly RGB isn't the best answer! And HSV is probably the worst possible because of its asymmetrical treatment of tints and shades. I would love to have the argument with people interested in colors, and maybe you could convince me, for example, that we should use the X11 crayons rather than mine for real-worldness.
Similarly, the real world, at least the real world of computing, doesn't use polar coordinates in graphics. They only use the upside-down Cartesian coordinates. So both the Scratch clockwise-from-north and the mathematical counterclockwise-from-east are abstractions. The original Logo approach, which Scratch inherited, was that kids intuitively see north as the "starting" direction because they see both actual compasses and the privileging of north in the compass rose on a map:
(which is that way, of course, because on a magnetic compass they paint the north-facing end of the compass red). I think that was definitely the right choice in Logo. In Scratch it's complicated, because most of their costumes, the ones representing people anyway, are vertical and facing east, so they end up giving sprites a starting direction of 90. That's a needless layer of confusion for beginners. For us, it's further complicated by the fact that our audience includes math teachers, who are adamant about ccw-from-east. Their reasons have nothing to do with what's intuitive for kids, so the question for us is whether we care enough about mathematical convention to adopt it -- well, that and the argument that costumes start out facing east.
That question, about measuring direction, is one that Jens gets angry about. He points out that it's trivial to write a library with blocks ANGLE and SET ANGLE that do ccw-from-east. And he's right. So the First Law of Engineering tells us not to change how we do it. I think if we implement student accounts and implement per-user startup libraries, I would then be totally in favor of not changing DIRECTION.
Anyway, the point of this long message is really just that you can't say "do what the real world does" in a language for learners. Otherwise we'd just teach Javascript instead, or anyway make the Snap! blocks exactly represent the JS primitives.