One important aspect of this proposal, which is all-but-glossed-over in the writeup, is that the AppArmor policies that allow uploading "untrusted" apps will specifically deny access to users' home directories. To allow reading and writing documents, there is a helper application (yet to be written, and yet to be designed, as far as I can tell) to allow opening files via a file-chooser dialog box. Superficially, this is similar to the sandboxing requirement of the Mac App Store. This has a couple of implications.
First, applications that depend on accessing multiple files, manipulating directories, etc. basically cannot work with this restriction, since you can only pass them a single file. I recall hearing that a few programmer's editors on the Mac App Store have no version control integration, because that would involve watching a whole directory and its subdirectories. The file chooser API has no way to say "and permit access to this subdirectory".
Second, unlike the Mac App Store, there is no per-application sandboxed homedir that can be accessed without prompting for permission. (On the Mac, a sandboxed application has access to ~/Library/Containers/com.example.whatever.) This means that, for instance, games can't save high scores or paused games, applications can't save preferences, etc. etc. without prompting you to select a preferences file!
Lastly, and most importantly, accessing files this way is a completely different API from what Linux developers are used to. On the Mac, it's easy enough for Apple to modify the standard Cocoa open-a-file dialog box API call to instead go through the helper app, and to internally deal with the returned file handle within the Cocoa libraries. On Linux, there isn't really a standard API -- there's a Gtk+ dialog and a Qt dialog for apps using those frameworks, but the spec implies that many apps may be using neither -- and receiving a file descriptor from a privileged app is a complicated piece of code using UNIX sockets and ancillary messages that very few developers are used to. I'm skeptical that app developers will be able to adapt to this new API and restrictions, and find it easier than just getting their app packaged the "normal" route (through Debian), which is what this proposal is attempting to sidestep.
I genuinely wish them luck with this, since I'm convinced that this is roughly the form that application security will need to take in the future, but I'm not convinced there's enough awareness of how important it is to make this work and work well, given how brief the mentions are.
I have been meaning to read the proposal more carefully and see if there's attempts at solving any of this before commenting on the mailing list, but I figured I'd mention it on LWN if it's getting prominence here.