The matrix focuses on two aspects: object security and record visibility. Specifically, who has permissions to do what with each object, and who can see what records in each object.
To control the "doing", the most straightforward way is to use object permissions with profiles and permission sets. However, it is conceivable that less admin-friendly and user-friendly options can be used to prevent certain operations. Below are a couple of examples:
- A validation rule can be used to prevent editing closed opportunities
- A Process Builder process could fire an autolaunched flow that reaches a fault condition, causing the create or edit operation to fail. Although I doubt anyone would do this right now, not only because it's cumbersome to implement but also because the error presentation in Spring '15 is not very pretty.
- An Apex trigger can be used to add errors to a record, thereby preventing the create, edit or delete operation
To control the "seeing" of records, the only practical means are to use the role hierarchy, teams (where applicable) and sharing rules. However, I do want to point out one technically possible way to restrict visibility in the UI, and that is to use Visualforce page overrides for standard actions. A Visualforce page could use the init action to route the user to a different page based on record and user criteria. While in theory the approach would work, in practice the override would fall flat because of incompatibility with Salesforce1 and because users can create reports or list views to see the "hidden" records.
