Let's say you have a custom inventory system. You have defined which unit types or which units get to have which setup of that inventory system.
So normally, a unit is created. You want it to have this inventory on itself without you coding it explicitly. You do this by detecting when a unit is indexed, then you create an instance of the inventory and associate it with that unit. When the unit is removed from the game, that inventory instance is basically a leak if you do not remove it right away. At this point, you have no way to directly reference it, and it will stay in memory, new units will be created, new inventory instances will be created, and so on, but the upper limit is 8192 and you are bound to reach it sometime because you are creating, but not DESTROYING instances.
Now, if you have a unit indexer system, you can use the onIndex functionality to give the unit the inventory as soon as it enters the map (is created), and destroy the inventory instance as soon as the unit is removed from the map (either explicitly removed, or dies and decays). This makes sure that instances associated with units are removed in a consistent manner.
Spell instances are the same, if you have a spell instance or a custom buff that does something to the unit periodically, you want it to be destroyed when the unit is removed from the map (sometimes as soon as it dies). You can trigger onDeath behavior yourself, but still leave the onDeindex behavior to the indexing system because it knows how to detect unit removal.
If you don't remove this instance, and it periodically does something to the unit, eventually it will start referencing a unit that no longer exists, and you are going to get bugs. With an indexing system, this won't happen as long as you add an onDeindex callback for your system, that destroys the instance(s) associated with the unit that is getting deindexed (removed from the map).
UnitIndexing is a good example of
separation of concerns in coding, which is important to make the code clean and easy to debug, as well as make sure that your scripts do what they need to, and not more, as well as make as much code as possible - reusable.