Adding a user in Central Administration > Application Management > Policy for Web Application will OVERRIDE any independent settings within that Web Application. Once revoked, their permissions goes back to what it was before they were added. (That is, if they existed at that site previously.)
A subsite to a site may use separate permissions if on creation of that subsite, you select "Use unique permissions". Or you choose to "Edit Permissions" from the 'Site Settings' > Permissions page, under the "Actions" menu. You can revert back to using the parent site's permissions by choosing "Inherit Permissions".
As long as an object (be it subsite, list/library, or document/item) is set to "Inherit Permissions", it will inherit permissions from the parent object. If "Inherit Permissions" is turned off in a child object, and a permission is granted in the parent object, that permission will not get passed down to the child object. Inherit permissions can be turned back on for all objects except in the original/root site collection.
Group management is important: If a user is in a group, they do not need to be explicitly given permissions for any object that grants that group permissions. Groups can be given specific permissions in relationship to specific objects, as well as a default set of permissions. (ie, normal read permissions site-wide, but write permissions for a certain library)
Also, the "Site Permissions" is the equivalent of a group that all offspring objects inherit, if they use "Inherit Permissions".
You can add more permissions (ie, write, delete) and override the group or site permissions by modifying an object's permissions directly and adding the user. However, there is no way to subtract permissions from a user that's in a group (and the group has been granted permissions to an object). (think colored glass - by adding different sheets of glass, you can change the colors and make things darker, but you can't add a sheet to remove a previously added color.)
There is one exception:
Permissions set on the Web Application are more powerful: one can use the "Manage Permission Policy" (from Policy for Web Application) to create specific policy levels - where specific permissions can be denied. Denying permissions prevents users from ever having that permission.
[edit 6/14 1PM] some clarification changes in the second to last paragraph. Also...
**DISCLAIMER** This information is not reliable. It's built from my trial and error, toying with SharePoint experience, as notes to myself.