Apple apologists often claim that these hurdles improve the user experience by acting as a sort of quality control. Sometimes a comparison to the "Nintendo Seal of Quality" is made.

The Nintendo Seal of Quality was developed by Nintendo in the 80's as a response to the "video game crash" that happened earlier that decade. One of the reasons for the crash was a glut of crappy games that made people wary of buying games in general, and eventually lead to the (albeit, prolonged) death of Atari and much of the video game industry at the time.

On the one side, this rule should be good for quality. Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy.

...

The iPhone OS Kindle app is excellent, a worthy rival in terms of experience to Apple’s own iBooks. The Mac Kindle app is a turd that doesn’t look, feel, or behave like a real Mac app. The iPhone OS Kindle app is a native iPhone app, written in Cocoa Touch. The Mac Kindle app was produced using the cross-platform Qt toolkit.

There are a few serious flaws with his reasoning here.

First of all, there's the question of whether cross-platform toolkits have ever produced top-notch native apps for Apple platforms. (The "for Apple platforms" qualifier here seems superfluous to me, but I'll let it go.) He claims that they never have, but I doubt that he has actually performed a exhaustive survey of software for Apple platforms to determine this.

Virtually all software with a graphical user interface that exists on more than one platform makes use of some sort of cross-platform toolkit. While it's easy to spot a badly ported application, applications that have been ported properly are indistinguishable from ones that were written "natively". It wouldn't surprise me at all if a number of the "top-notch apps" Gruber uses actually do use a cross-platform toolkit without his knowledge.

In fact, Firefox is built using XPCOM, a cross-platform toolkit (the "XP" actually stands of "cross-platform"). One could even argue that WebKit is a cross-platform toolkit as well (though it's specific to HTML rendering, rather than being a general GUI toolkit). So if Gruber is right then none of Safari, Google Chrome, or Firefox are "top-notch native apps".

But for the sake of argument, let's say Gruber is right and that cross-platform toolkits really have never produced top-notch native apps for any Apple platform. It doesn't matter, because the "cross-platform toolkits" argument is a complete red herring. Take a close look at the text of section 3.3.1:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

There's no talk about toolkits here — it's talking about languages. There is nothing about this rule that prevents you from using a cross-platform toolkit provided that it's in Objective-C, C, or C++. Qt is a C++ toolkit, so if it weren't for the fact that it relies on a pre-processor (which is unusual for cross-platform GUI toolkits) then there's nothing about section 3.3.1 that says you couldn't port a QT app, like the Kindle application, to the iPhone OS.

Some of the things section 3.3.1 actually will prevent are:

Writing apps in other languages that teams may be more proficient in (Lisp, OCaml, Erlang, Scala, Python, Ruby, Java C#) even if C, C++ or Objective-C is used as an intermediate step.

Using existing libraries written in other languages. For example, many numerical libraries are written in Fortran.

As a software engineer, I'd be very surprised if any of the above had a correlation with lower quality applications. On the contrary, it tends to be the more proficient software developers that use a wider variety of tools, including ones like those listed above. (Luckily, actually identifying apps that violate this policy would be very hard, if not impossible, without the source code. If it weren't for this fact, we'd likely see a number of existing apps get pulled off of the store.)

Other App Store policies have similar problems. For example, it seems extremely unlikely that containing an interpreter is positively correlated with low quality. Instead, the no interpreters rule locks out a certain class of app. You cannot have a PostScript or TeX viewer without an interpreter, for example. Emulators for old machines are also affected. (Technically an emulator is an interpreter, though Apple seems to allow emulators as long as they don't let the user supply new code to be emulated/interpreted.) Even Safari runs afoul of this rule given that it includes a JavaScript interpreter, but of course Apple doesn't need to follow their own rules.

But never mind what I think. Even if the intent behind these policies was to keep low quality apps out of the App Store (which is hard to believe) the fact that the App Store is full of crappy apps is evidence enough that they've failed in this regard. These policies don't work to keep low quality apps out. The various high profile examples of apps that have been either disallowed, left in review limbo or lobotomized also speak strongly against the notion that Apple's policies have anything to do with improving things for their users.

So to sum up:

Many of Apple's policies don't appear to have been designed to improve quality.

If they were designed to improve quality, the large number of garbage apps on the App Store make it clear that they aren't really working.