Big Backlogs: are they worth it?

Previously I'd written how I'd reorganised a 500+ line spreadsheet of backlog items.  The backlog had, if anything, grown rather than shrunk.  The question then naturally arises:

What is the point of maintaining the backlog if most of it is never used?

There is a sense that discussions around backlog items would be wasted if those items were not recorded and prioritised in some backlog.

Different potential customers had presented many features that they'd required, and all of those were recorded.  Though customers and potential users carried on without those items as the sales were not secured.

(Maybe a better sales approach was required: get agreement on purchase of the core product then provide incremental delivery?)

A similar question can be raised regarding large bug lists:

What is the point of maintaining a backlog of hundreds of bugs?

If users can continue quite happily using the product then what is the point of maintaining a backlog of hundreds of bugs, particularly bugs which go back years?

This also raised the question:

Why is there such a large list of bugs in the first place?

If the first iteration of a product is poor there will be many bugs reported.
If the first iteration of a product is also large there will be many more places to find more bugs.
If the bugs are not addressed in the next iteration but more features are added then they will remain.
If development continues with the same level of quality then more bugs will be produced for the new features.
Result: even more bugs.

So, how to stop having and ever-increasing number of bugs?

You can stop the flood of bugs by:

1. starting with a small set of features in the first iteration, so there are fewer places for bugs to lurk
2. building quality in from the start, by not attracting bugs in the first place
3. continuing in future iterations with few features and high quality

But what about a big backlog?

If you start off with a small set of features aren't people still going to ask for many more features?
Yes, but you still have to prioritise which ones you're going to do in the next iteration.

Should the features not implemented in the next iteration continue to be recorded?
If after iteration #1 feature X is requested, but it's not implemented in iteration #2, it may no longer be relevant when it comes to iteration #3, other feature requests may be made as a result of viewing and interacting with the product produced in iteration #2.

Therefore, features that are not implemented should be aged and eventually dropped from the backlog, thus keeping it small.