I don't know about you, but it's become clear to me that putting user data into files on systems and putting system data into the same types of files on systems has led to many of the troubles we have with system security today. User data should never have been allowed to mix with system data.
In general, sand boxing in various forms works to prevent this problem.
In the article, the author complains about not being able to grab screen shots or not being allowed to communicate with another process. In fact, a better model than shared files is for the system to provide a service which apps can access. The system could provide a screenshot service that can take a screen grab from the display system and offer it to a client app. Interprocess communication services have been there all along.
There's a long rant in the article about plugins. I'm not sure how important plugins are, but I can see a service that registers and stores plugins if a plugin needs to be shared by multiple apps. If it doesn't, if a plugin is app-specific, then there should be a service that allows each app to register and store it's own plugins. They don't need to go into files. No data does. Files just contain data and the data can just as easily be stored other ways.
An architecture like this is actually better all around and doesn't preclude functional software. In fact, a service-based architecture like this provides for more easily moving parts of the architecture to other machines, if the communication can occur over a network.
I, for one, welcome our new service-oriented architectures. If there's a down side, it isn't clear to me yet.