One reason to go for some kind of structural rules in an on-chain alias system would be to simplify compatibility with existing systems.

For example, if the . character was always used for DNS-style subaddresses, we could have the "com" alias reserved for ICANN or whoever manages the .com TLD, to bridge the old .com names over with reverse compatibility.

If the @ character was always used for addresses like NIP-05 or email addresses, and that was combined with reserving TLDs like "com" to whoever manages them, we could keep the system compatible with NIP-05.

We could have a TLD like .coin where it's reserved for anyone to add after their alias with no actual function, just to make it sound like a .com name and feel more natural to boomers.

Or, we could leave all that stuff up to individual apps to decide. Nostr apps using NIP-05 style aliases could have their own spec for not recognizing registries with @ characters or the name "com" or whatever. This makes compatibility more complicated, but also more versatile.

nostr:nevent1qvzqqqqy9spzqamkcvk5k8g730e2j6atadp6mxk7z4aaxc7cnwrlkclx79z4tzygqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgewaehxw309ac8yetdd96k6tnswf5k6ctv9ehx2ap0qqsg6ar8333hk5w6alr3mae7nuf3p7sv4zfr3644dasqjmdhl20ph2s766uxg