the key statement in TFL is it 'makes security reasoning explicit and direct'. It addresses the software architecture problem that you mostly cannot reason confidently about the security of an application -- you cannot be confident that even a team of infallible programmers could produce a secure system because there is no way to exactly explain the right rules that would result in a secure system.
In this respect, application software architecture mostly lags behind network, OS and DB security architecture, where authentication and access control work in a way that allows for reasoning about the security, i.e. you can assert 'if this authentication and access control is implemented correctly then these resources will be secure, except from bugs in a lower layer of the architecture.'
Example: when you create user accounts on a *Nix or windows machine, you do not have to inspect all the applications on the system to confirm that none of them let user X access user Y's home directory. You can reason that the O/S's access control stops applications from doing that unless certain conditions are satisfied (eg user X is listed in the sudoers file).
This what you _can't_ do with most application software. An example : data driven applications which store data for thousands or millions of users will typically not create thousands or millions of DB logins each with controlled access. Instead, the application will use a single login for all users and rely on logic embedded in - and scattered throughout - the application code to stop user X seeing user Y's data. To verify "X cannot see Ys data" requires all the application data retrieval code to be inspected. All maintenance of this code risks introducing a leak.
This project appears to offer to close that gap in application security architecture. It's progress. Yes there are frameworks out there that address application level security, but having it embedded in the language is the right approach.
