Here are some thoughts:

• Measure the ceiling of requests with a archetypes object. I had done some measurements that with a view that was rendered on a AT object that pulled a few attributes off of it.  That the performance would get worse and worse with each attribute call to AT.  I imagine if you measured the ceiling of rendering a view on a AT object.  Then watching the decrease as you call 1-100 attributes on the object.  This might show some interesting issues.
• zpt is very slow.  What makes it so awfully slow is the security checks and the tal expressions.  So this is known issue.  I wouldn't try to make ZPT fater or anything.  I would simply recognize it being slow.
• caching is not a panacea.  I would really suggest to focus the sprint and not talk about caching.  We should reduce the number of caches instead of increasing them.  Or relying on caching as the way out.  If the system is fundamentally flawed caching will just gloss over the problems.
• look at security checks.  I bet if you count the number of security checks per page view.  They range in the hundreds and even thousands. If this is the case - it sounds like we could shave off quite a bit of work by changing the security model.
• existing caching could be optimized.  Since we call run multiple-zeo clients.  If we could share a cache we could increase throughput and reduce memory.  This might be a win.  Memcache is cross platform (we run it on windows).  There may be some insight on performance.
• really try to reduce the scope of the sprint.  i.e. don't try to optimize the 'startup' of plone.  Try to focus on the 'runtime' page-to-page flow.  What a user experiences.
• enfold and lovely have found that 'page composition' in zope is very expensive.  We are taking two alternatives to fixing this.  Lovely thinks that javascript is the way on the client machine to compose pages.  Enfold is working on xslt and doing page assembly outside of zope (in apache or IIS) using enfold.lxml (in our public repository).
  

Tools

• I use a combination of selenium and jmeter.  Jmeter is superior to most other load testing systems.  You can either be very simple with it or very complex with it.  Also its actively maintained and used by google.  It is important that if we invest - that we invest in tools that we don't have to maintain or program.  I think funkload might be dead.  And it certainly doesn't have the development mindshare that jmeter has.
• selenium works quite well with multiple threads or multiple browser windows.  Often we have selenium doing writes in multiple browsers and having jmeter beat on the system concurrently.  It's a simple and brute force way of stress testing.  And since its simple it works ;). Selenium also has mindshare in the plone community.

Btw: I'm writing this in a way that may seem like I'm telling you.  I'm not.  I'm simply offering suggestions.  I hope it doesn't come across like I'm telling you what to do.  Just don't have time to write it in a nicer way ;)