I am going to strongly disagree with the statement “Therefore, from a practical point of view, sequence_items are unlikely to be overridden” (Cookbook Section UVM/Sequences/Overrides).
I am going to provide two examples of how type overrides with sequence items has been very useful for me.
While I do want to test the entire state-space of possible stimulus, I often want to narrow my stimulus for certain tests. By heavily constraining my stimulus I am actually able to hit certain scenarios. An example could only running maximum or minimum size packets for an extended duration. If I need to run a large number of these packets in a row to create a scenario, then this is unlikely to happen without additional constraints. I could do this by writing a new sequence that constructs these derived sequence items that have additional constraints, but that seems like it would be slightly more code and more files than extending a sequence_item and using a type_id_override().
My other example is that I often find bugs and sometimes I am not responsible for fixing them. However, I still want to find other bugs while that bug is being fixed. Therefore I create a test that exhibits the bug and document it. However, I then introduce new constraints in a derived class to mask the bug and have all my other tests use type overrides to enforce these constraints. This allows me to temporarily mask known issues while I hunt for more bugs or work on adding more coverage.