Why not multiply "six confirmations" and divide Time-Between-Blocks and Reward by the same factor? It seems that choosing a good factor to use to expand Bitcoin's capacity is a good idea.  The software would divide some of its calculated values by this factor, such as the target time between blocks during difficulty calculation, the number of blocks between difficulty adjustments, and the subsidy.  To achieve the security of "one hour's worth of hashing power," the recommendation for confirmations would be multiplied by this factor.  It seems that using a factor of two from time to time (whenever the community finds it valuable) would be appropriate.

Let's suppose we choose a factor N. This will allow the blockchain itself to grow N times as fast, providing N times the transaction fees to miners, multiplying the number of rewards by N (but dividing the reward itself by N), dividing the average wait for a confirmation by N, and multiplying the rate at which transactions are confirmed by N.  This also reduces the variance of mining revenue.

This allows time (instead of network bandwidth and computer memory) to be used to expand the carrying capacity of the bitcoin ecosystem.  Should such a proposal be written into a BIP?

The objections to this idea so far have been answered in the comments.  If anyone feels that there is an objection adequate enough to drop the idea, please post an answer.  If anyone wants to create a BIP, please let me know so I don't have to do it myself.  I don't mind doing it myself, but I'll probably be slow.
In consideration of replacing the 1 block with N blocks in the same time frame, N &gt; 1, I see the following points:

Advantages


Expected time until first confirmation is reduced
Mining revenue is distributed smoother among pools
Capacity of network is increased
Smaller peak traffic than increasing blocksize by N


Disadvantages


A hardfork is required to adjust the block interval
Increased chance of chain forks and higher stale rate due to block validation taking a larger portion of block interval
Thin clients need to store a larger amount of headers
Slightly bigger bandwidth usage than larger blocks




Still, it may be that 10 minutes is too conservative and a smaller block interval would provide an overall benefit. For example, at Scaling Bitcoin Milan, Arthur Gervais presented simulation results that he interpreted to suggest that Bitcoin could safely use 1 minute blocks.

CoinDesk covered the topic in A Lower Block Time Could Help Bitcoin Scale, But Will It Work?.