My understanding is that applications won't be able to see other users's files. Sounds like UNIX to me. And, gee, that's been around for only 40 years.
First of all, Unix did not invent file permissions. Not by a long shot.
Other than that, well, this is a permission scheme, but finer grained and smarter than Unix permissions. Unix permissions are user based; it's primarily "who owns this file, and which users' processes are allowed to do what with it," with a few extensions like suid that are about escalating an app's privileges. So for example, vanilla Unix permissions will allow any process to access any file owned by the process' user.
The OS X application sandboxes being discussed, in contrast, are about what files or resources an application is allowed to touch, even if the application's process is owned by the same user as the file. So the sandboxes can forbid an application from surreptitiously opening files even when they're owned by the same user running the application. I.e., if one of the applications you're running gets compromised by a buffer overflow that allows arbitrary code execution, the injected code is not allowed to read arbitrary files in your account.
This of course exists in OS X together with Unix-style user-based file permissions. So in short, OS X can forbid a process from opening a file on two kinds of grounds: either (a) the process' user doesn't have permission to access that file, or (b) the process' application doesn't have permission to access that file. And in the latter case, there's also a trick that the OS and libraries work together to identify which files the user has explicitly opened through the user interface, and dynamically grants permission for the process to open those files.