I'm working on scalability issues with permissions as we speak, and I think it is safe to say that OpenACS 4 will outperform ACS 4 Classic in this regard. The LAUSD (Jon Griffin's employer) has already provided speed-ups for acs_permission.permission_p itself, and I'm poking around into the use of acs_party_privilege_map which is very slow in PostgreSQL and apparently not all that swift in Oracle, as well.
So this will remove one bottleneck. What other bottlenecks will we uncover? Hard to say. As Jonathan mentioned, more information on the actual number of pages to be served is needed in order to give you feedback, and as was mentioned later caching can help a lot, too. You can cache directly in AOLserver and perhaps have more fine-grained control over when to expunge cached pages than through the use of Squid or similar tools (only your code knows when a dynamic page changes, after all).
One thing we are working on is the provision of automated testing tools, and this includes load testing using scripts that "know" about the structure and perhaps usage profiles of a site. This will give users the ability to drive development sites with input that more accurately reflects reality (by posting to bboards, etc) than is possible with a simpler tool than (say) apache bench.
I realize none of this answers your question directly. In part that's because I think the scalability issue for [Open]ACS 4 has yet to be answered - I'm outlining the steps we're taking to boost performance and to enhance our ability to test performance (and correctness) later.
One point of reference for OpenACS 3.2 ... this site right here withstood a slashdotting when running PostgreSQL 6.5 on a single dual-processor PII 400 box.
