think of page level security as the primary security and module level security as only supplemental.

module security is secondary, when we added that it was not with the goal to encourage a lot of hidden modules on a page by view roles, thats ok in a pinch to have 1 or 2 on a page, but I would not treat it as a primary mechanism for showing/hiding things on a page.

the main goal when we added module level supplemental security was because we needed a way to grant a user edit permission on a module without granting edit permission on the page.

in general it should perform fine with that many pages and roles.

page management and role management might be a but unwieldy, we have an add on in our store, Page Manager Pro that can help with the page management.

the site map will be cached in memory and it is a little larger with that many pages but its not too much, this site probably has nearly that many pages and all of them are visible. other than use of a little more memory to cache the site map, the number of pages does not impact performance at all. 

users will only see the pages that correspond to their roles so the navigation experience should not be difficult for the users.

for roles, its ok to have lots of them, but no user should be in more than a few roles, user roles are stored in an encrypted cookie and a cookie can only hold a small amount of data, so if you add a user to lots of roles it will be truncated in the cookie and he would not get all of the roles into the cookie. the only potential problem with lots of roles is back end management of roles might become more difficult

the performance of individual pages is based mainly on how many db hits are needed to generate the page, which is why you want to avoid loading anything that the user is not going to see

performance will mainly be impacted by how many simultaneous users/requests and how much available server resources to process requests and how expensive is each individual request to process, ie how many db hits, how efficient those db hits are

no, that is not a good idea, probably cannot fit that in the cookie. it is not a fixed number though because the role names are stored in the cookie, so it depends how many characters in each role name, short role names would help but more then a few is still to much, you would have to experiment to find the actual limit

why would anyone need to be in 20 roles for permissions? surely you can structure permissions so that only a few roles per user are needed

without knowing what each role allows how can I suggest a hierarchy, here is strategy advice

it is better to have as few roles as possible attached to the user

it is ok to have lots of allowed roles attached to a page

think of how to use that info to reduce the number of roles per user

to be able to use more roles per user, you should use short role names but they have to be unique obviously

one thing to understand about that. when you create a role the name you enter is used as RoleName and DisplayName in the mp_roles table, roleName is used in the cookie so it must be short as possible but display name is not stored in the cookie so it can be longer.

once a role is created the rolename never changes, if you edit it edits only the displayname,  the only way to edit the rolename is directly in the db or by delete and re-create the role.

so when you create a role use a short name then edit it to make a more friendly display name

plan ahead the short names you will use for each planned role sinc eyou plan a lot of roles, create the role with the short name then edit it to change the display name