Where I see this most often is with companies that place a unusual high cost on servers, virtual machines or containers. In those cases I normally just application servers, that's a good a description as any. The only difference is that I won't thing twice about deleting a server called app01 and recreate it using Ansible, Puppet, docker-compose or whatever deployment tool that customer uses.
In my mind there aren't "pets" any more, and if there is that's a mistake that needs to be corrected. The customers I deal with who have pet servers are the most dysfunctional and the ones with the most challenges, both technically and organisational.
I think the approach of naming the host "freddy" works for small installations (and all installations in 1990 were small), where reinstalling a single server is a manual process and impacts your capacity, and where humans remember "Oh, freddy is the one with a very large hard drive." If you've got any sort of automation, let alone virtualization, you should be keeping facts about hardware somewhere other than people's heads and so you can index them by the actual identity of the hardware - the fact that web04 had a large disk last year is remembered by a field on your inventory entry for XY1Z234, not by any human. And reinstalling web04 as db02 is just a matter of running a script from the comfort of your work-from-home laptop - certainly no need to visit the datacenter.
I think this lines up with your point about pets being higher levels of abstraction - I wouldn't point any DNS client at dns01, since that's a specific server, I'd point it at a virtual IP that can be bound (possibly multicast) by any dnsNN server that happens to be up. That virtual IP is the pet and the API surface, and it belongs to no actual server.
In my experience, unless a server was a VM host (or, these days, k8s cluster), it was rare that it would be single function. We just didn't have the money to allow such waste of resources. So unless you had single-software with enough requirements to hog the whole box (usually DB servers), then everything tended to have multiple functions, and reimaging was rarer event.
So I prefer to have "Freddy the web serving system", which might contain several machines named in style of R04-24.SFO.i.contoso.com ;) - because "freddy the web serving system" is the part that I care, and individual components enter everyday care only in the metrics of capacity planning dashboard.
This is emphatically not true beyond a certain point, perhaps around 500 boxes or so. My last job involved working on a fleet of about 15,000 hosts; I can promise that extremely few of the servers were precious pets. They really were cattle, and we would blow away and reimage them into different functions (with hostnames matching the function) moderately frequently.
In the case you described, whatever drives the replacement system is the pet - the so-called cattle are just "components" that became interchangeable for the bigger "pet" system. As another commented called it, you need good names at the edge - where the edge for me is the level where you care about the system. We used to care about individual components of a computer and those would be effectively "pets" of the time. Nowadays, you do not give name to a DIMM in your server nor take extra care to ensure it works. And so on, till you reach the level you actually have to care, and that's where you need to name it (IMO) because that's your pet, even if it's composed of what people call cattle.
As for hostnames matching functions - I found much more use when making hostnames reflect basic type of hw and physical location, and would keep the name as long as the location didn't change. The rest depended on what functions were currently applied to the machine.
But the problem with that logic is that the name is not only attached to the metal, it's set (and mostly so, I'd argue) in software, as the OS hostname. And then what happens next is that the motherboard of that precious pet melts down and you scramble to move those drives to a spare, and now you have two metals with the same name.
It just doesn't work so well.
And your fancy random or pseudorandom looking naming scheme is cool and fun until someone new comes in and asks you wtf colchicifolium is...
Name machines on purpose. If the purpose changes, the OS will likely follow as well. If not, renaming shouldn't be that big of a deal, or, to put it another way: if you can't rename, you can't reinstall, and then you'll fail.
Now naming hardware is the "fun" part. when is the last time you did an inventory of your motherboards? or is it disks we're naming? the raid array or individual ones? how about memory sticks? or do you only name precious server cases? ;) after all, that is where the label ends up...
But if a pet "melts", well, the pet died. You moved the functions over to another pet. Whether it's a move from Zeus to Jupiter, or rebuilding your precious cattle management system on eu-central-1 after us-east-1 burned down and you got slapped with data locality requirements, is less relevant ;)
Have individual hw named in unique way that isn't related to functionality it runs, then use CNAMEs specific to functionality - i.e. never point a DNS client at "freddy.dc.somecorp.com", you point it at "dns01.dc.somecorp.com".
The decision on what machines need unique names, not just pseudorandom IDs or similar crap, is well described by another comment here https://news.ycombinator.com/item?id=26054487 - which I like to put as "named systems are the systems you care about"
In fact, I'll go with seemingly unpopular opinion that there are only pets, never cattle. The pets just happen to have components, but at some level of the stack you're hitting a precious pet. Even if said pet is "us-east-1 Lambda service"