If they are looking to add 10m items per year and retain content for 2-5 years, then I would probably design the initial system to support 30m items and grow it as needed in 2-3 years. Business and technology changes may require a different topology at that point.
One Crawl Server / Index Partition can support up to 10m items. In many cases you will want to plan on that being smaller since the amount of time it takes to do a full crawl will be directly related to the hardware capabilities and the number of items in the index. I typically try and plan for 5m per index; if anything this gives you a buffer.
You also need one or more query component for each Index Partition. If you look at the farm that is why you see the query component duplicated across multiple boxes for each index partition.
Following the logic above if you plan for 6 Index partitions you would need 6 crawl servers and at least six web front ends, supporting six primary and six redundant query components.
With all of that said, I push pretty hard for FAST with any installation where you know there will be more than 10m items in the index.
Update to address comment:
A single WFE is a bad idea unless the system really isn't critical or only has a small number of users. There are a number of reasons to load balance that have little to do with scalability.
It is also very important to understand the impact that crawling has on the system overall. In most small 1-3 server environments with any real content, the biggest performance issues tend to come from Search because the crawl hammers the system's ram and cpu. The Web Front End is overwhelmed which then impacts regular use of the content. Your six crawl servers cannot be serviced by a single web server. The number of WFEs will limit the number of query servers and index servers you can support.