I can see how something like that (saying plugin X should be treated as if it was Y) would be useful. I think there's also overlap with the case where people merge plugins together, e.g. plugin X should be treated as if it were plugins Y and Z, so I think it would make sense to cover both with the same feature.
Off the top of my head, there are a few questions that need to be resolved for this:
If X is an alias of Y, should X be allowed to have its own metadata, or should any edits you make be applied to Y?
If you've also got Y installed, should that be treated as an error?
If it's not an error, would you always want X and Y to have the same metadata? If no, X should be allowed to have its own metadata.
If Z is also an alias of Y, would you want metadata applied to X to also apply to Z? If no, X should be allowed to have its own metadata.
If X is allowed to have its own metadata, it would get merged on top of Y's metadata following the existing metadata merging rules that are used for regex entries and masterlist/userlist entries.
Is there any reason to disallow Y itself from being an alias of Z?
If nested aliasing is allowed, that introduces the possibility of circular aliases, e.g. X is an alias of Y, Y is an alias of X, and this would need to be checked for when trying to resolve aliases.
Either way, we'd have to not use aliasing in the masterlist, because there's no telling what plugins users have aliased, so adding an alias could cause unexpected breakage. This is OK as regex plugin entries allow similar functionality for masterlist maintainers.
If X is an alias of Y, what happens if Y has no metadata defined? The obvious choice is just to say that X inherits no metadata.
If X is an alias of Y and Z, there needs to be a defined order of aliases to make metadata merging consistent. E.g. if Y depends on A unconditionally, but Z depends on A conditionally, you'd want to override Z with Y.
If you need to pick and choose, it's up to you to apply the necessary metadata to X yourself, I don't think it's worth providing more granular aliasing functionality.
This would be similar to YAML's alias/anchor features, which pretty much provide this, except that it does only one level of merging, whereas LOOT would need to do two (e.g. to merge incompatibility sets, not just pick one set). This feature also overlaps with regex plugin entries, which can apply metadata to multiple plugins from one metadata entry, but users can't change masterlist plugin entries to matchmore plugins.