I can think of at least one case off the top of my head. My site has 65,000,000 posts. While SELECT queries against it (LIMIT or otherwise) are still reasonably fast, operations against that table such as changing table schema (or adding an index) are not. MySQL essentially copies the table being modified to a tmp table, performs the modifications, then replaces the existing table (all while locked). Even on our quad quadcore box with 16 gb of ram, modifying a table of this size takes a very, very long time (during a vBulletin 4 test upgrade, an index addition took 6+ hours).
Personally, I'd rather the post table is sharded, with the id of the sharded post table kept in the thread table, and new posts being inserted into the correct table. Yes, it's a lot more complicated, but it scales. It's easy enough to use a mysql_merge table to select against, we've been doing it for many years.
I realize this is "enterprise" functionality, but I figured I'd mention it anyway.