To express some concerns I have about this:

If it's a matter of splitting entities into their own classes and savegame IDs, then that is good. The only confusion that would arise is when old commands don't work, and the explanation of "why" is simplified ("they are now their own entity with ID: [savegame ID]").

But if it's an alias like "LightningBolt", then it will be a cause for confusion that is harder to explain and inherently harder to understand.

"LightningBolt" isn't a savegame ID. It's only an alias for /summon's base syntax to create a lightning bolt entity, and thus cannot be used anywhere else (passengers, spawners, spawn eggs).

But the type selector parameter obtains a list of valid targets from /summon's auto-complete list, which includes "LightningBolt". Since that's not actually a savegame ID, it should be throwing an error when specified but instead will accept it. It will still not be able to target lightning bolts for three reasons: it's not a lightning bolt's savegame ID, lightning bolts don't have a savegame ID, and lightning bolts are not included within selection in the first place (which is why @r[type=!LightningBolt] can be used to target a random entity of any type, and would also be the case if more aliases exist).

Folks would try to use selectors with aliases as input, but it would not target the entities they want it to (because it's just an alias for /summon). Even if an error is thrown about an invalid savegame ID, it would not stop the connection made between available targets in /summon and available targets in selectors, as well as nested NBT input such as for passengers or spawners.