Your database migration example is about technical tasks. Often, technical tasks are timebound.

The article is not about technical tasks.

Big themes like “Book flight” in the example live on beyond releases, until either the functionality is removed, or the product is taken off the market. It does not make sense to say they are done, because anytime, new details may be added to enhance the product.

Yet they are crucially important for the success of the product, since they directly tie to user needs. It makes sense to be aware of them, but the backlog is not the right place, since they are not used up.

On the other hand, there are small user stories that fit into a sprint. They are timebound. Once they are done, they can be deleted or archived.

So my advice in the Dissolution chapter means: don’t even try to break down the big themes to small stories in detail, before development. Instead, create a rough map of possible options (like a story map). Then, deliver a small increment to users that possibly gets you in the right direction, and get feedback from them. You may be wrong even the first time you deliver, and then a detailed upfront plan would turn out as a complete waste of time!