I miss the old NIC names, but for systems with multiple NICs the old way would name them differently based on the winner of the init race. It often felt deterministic, but was not.

I've had critical systems fail on reboot because the NICs swapped names so WAN port got configured as LAN and vice versa. That can also create a terrifying security problem too

Some distros wrote config files so the assignment would remain stable.

Which also was wrong when switching hardware around, but that's a different issue.

It provides predictability in the device names. enp1s0f0 looks cryptic but it tells you the exact slot location of the card

eth0 tells you the first ethernet class interface that was activated that boot. Not particularly helpful.

I feel like if you need to care about these names as a user... the distribution has failed to provide effective wrappers. This is window dressing.

Yes. When we got a shipment of 1000+ servers that are all supposed to be cabled the same way, both internally and externally, the device naming made it easy to see when something got messed up. This allowed us to hold the system builder accountable, simplify our configuration management, and reduce the amount of configuration discovery a engineer needed to do during an incident.

Very good examples of the practicality!

While sure, I would like shorter device names, the fact is... the only time I need to use them is when ambiguity is something I/we can't really afford.

So, I'm thankful for the cryptic-yet-specific names.

Everyone else (read: desktop people) can use whatever DHCP'd.