Part of the 'standard' model for security is to make every component as sandboxed as possible. The problem is, programs need to be able to access the system, and if the attack compromises the program it can do whatever the program can. For example, most web browsers have the ability to show html pages that are stored anywhere on your file-system. This means that if your web-browser gets infected, the attacker has full read access to you files. You can (and I do) sandbox your browser to only its files, however you then loose the features that depend on full read access.
Of course, the instance of the javascript VM that is running the javascript from the website does not need filesystem access, so it can be, and normally is, sandboxed.
> The problem is, programs need to be able to access the system
Not necessarily: to be on the Mac App Store, an application must access only files in its own resources (configuration and so on) or through user interaction (open file dialog). If your web browser gets infected, it gets full read access on every file you willfully want it to read. Problem, you cannot have a multimedia player that opens m3u playlist files in this model: see http://mplayerx.org/leave-mas.html
Of course, the instance of the javascript VM that is running the javascript from the website does not need filesystem access, so it can be, and normally is, sandboxed.