Requests aren't the problem. The slowdowns that indexers see are the result of having to parse through tens or hundreds of groups, group together millions articles, perform analysis (media info, password protection etc), and recheck incomplete releases for new articles.

You will run into exactly the same slowdowns as the indexers that serve 3,000 day old content. Take a look at drunkenslug for example. This is an indexer, that from the benchmarks I've seen posted on here, has a high response time.

The stats on the front page for this indexer right now are:

Todays Avg. Bandwidth: 173.46 Mbit/s 
Latest Release Created: 3 minutes ago
Releases Added In The Last Hour: 1177 
API Calls In The Last Hour: 49370 
Grabs In The Last Hour: 2426 

Despite only serving 13 requests per second, the server still has an average bandwidth of over 21MB/s.

With only 13 requests per second, and a presumably well indexed and well maintained database, the server shouldn't even be breaking a sweat. Those kind of numbers would barely even register on bandwidth, CPU or disk IO.

All that bandwidth is no doubt going directly to ensuring that every article from every group they index (a quick check on the groups page shows a whopping 291 groups actively indexed) is accounted for and properly processed.

In short, you would not be able to skip on any of the heavy lifting by only performing indexing for recent content only.