Well, here's a very good example why. The Russian-writing community (in the informal sense of the word) on LJ numbers about 900 people currently. There's a user who adds to his friends list all Russian-writing LJ users who can be discovered (in other people's comments, in other Russian-writing people friends' lists, etc.). This is done specifically in order to allow people to read all Russian LJ journals in that user's friends view. This fact is widely known among Russian-writing LJ users, and many dozens of people (a counter's been used to measure) read that user's friends list daily in order to find new interesting journals in Russian, and to keep up with many interesting people. I do that daily, for example; the relevant link is right there on my browser's toolbar. In reality, of course, not everyone of 900 people on the list updates daily, and though some others update several times a day, I (and other users using this) manage.
You wondered what could possibly unite 1000 different people together in one list? So here's one possible answer for you: language. For all I know, people writing in other languages may be employing the same method currently on LJ. I wouldn't be surprised.
Of course, at some point doing that will become impractical - maybe when the number reaches 2000, or 5000, who knows (the community grows fast: just a month ago there were 600 people in the list, two months ago - 300). But it's certainly not impractical yet; in fact, it's hugely beneficial to very many people.
I strongly feel that the number of friends should not be limited at all, with a possible (and still undesirable) exception of a really ludicrous number. 100, 200, 500, 1000 are not such numbers; 100,000 may be.
The discussion on how such a large number of friends harms LJ's server resources has centered on the userinfo page issue, and I feel that this is not that big an issue. The real issue, for which I haven't found any answer is: does using the friends view impact the server in any severe way? My gut feeling would be that it doesn't, not with 1,000 or 10,000 users - considering e.g. that the stats page is happily showing the latest 10 updated journals among all the 250,000. However, someone probably knows better about this -- please speak up!
As for the userinfo page, the performance impact here surely can be
reduced without putting any hard limit on the number of friends. For instance, why not add an argument with a max number of friends to fetch to the 'getfriends' protocol mode (for compatibility, make it an getfriends_ext mode)? userinfo.bml could then use that argument in order to fetch no more than say 500 friends to show on the page. Or, the number of friends can be maintained in the database (rather than dynamically computed) by the code that adds/removes friends, and that number can be checked when fetching a friends list from userinfo.bml; in case it's too large, only display the number of friends and not their names. Or... there're many other possibilities. If that's the real problem, let's discuss it and solve it, rather than crippling users with an arbitrary hard limit.
Thanks for listening! I'll be getting off my soapbox now.