I find pretty interesting that the memory is not perfect out of the fab and its defects are coded on its label, hence these defects can be loaded to the device using it as a map, so it can work around these loops while working.
Now, this is even true for flash memory, but this is handled at the controller level and its dynamic during its initial "formatting" at the factory, so it's completely hidden from the host unless "host" is the controller.
OTOH, bubble memory comes with a "this machine has no brain, use your own" sticker on it.
Hard disks used to come with a paper label listing their bad sectors. (They still come with a list, it's just now it is hidden in the firmware like you describe.)
I do some retro-computing every now and then and of these old drives that still work (about a 50% chance), when I format them assuming all sectors are good, they will inevitably report the same bad sectors as is on the label.
I don't really know why "bad sectors are still bad after 40 years" is so surprising to me, but there you go.
There's a step which "flashes" the magnetic structure on the disks during manufacturing which also allows drives to navigate the disk surface and "see" individual sectors. The bad sectors list from factory shows the points where this process has failed due to bad coating or other anomalies.
So they are not worn out sectors, they were bad (or not there) from the start. You can't rub them out, because there is not enough magnetic flux or material to store data at that address.
I remember someone writing a rant against having the list in firmware and managed automatically by the drive. If the list was on the host side, your software could route around the bad sectors and minimize the total amount of seek time during a program run. But with the drive managing bad sector redirection, you could never predict read latency since any read could get re-routed to a spare sector by the drive, adding latency outside your control. Everything still became automatic though.
You could buy disk packs with no bad sectors back then if you wanted that ("bit error free"). They cost extra but the premium wasn't all that high. Of course they could still develop bad sectors later.
And the firmware remaps them, as far as I know. That's very different from a firmware exposing a bad sector list to the host, which is the case for some flash systems, I believe.
Disk firmware follows sectors which are hard to write, flags them as "current pending sector". Then reallocates that sectors data to one of the reserves when it has time and increases "Reallocated Sector Count", and if it deems the sector dead or unusable, it's get blacklisted and "Offline Uncorrectable" count is increased as well, from what I remember.
This is all transparent from the host, maybe an occasional "wait a little, I'm kinda busy" signal to the controller. Same for flash, but it's way faster and more transparent, since the real map inside the flash controller is never linear, anyway.
Not nearly all flash systems (including NAND based ones) use a dedicated controller. I believe e.g. iOS devices have for a long time still handled bad block handling in software, while macOS has always handled it in hardware.
Systems running macOS (i.e. Mac systems) use SATA or NVMe disks (depending on their age) which come with their own controllers, hence it's always isolated from the OS except SMART data. I have no idea about iOS systems.
Controller based management is also true for SD cards of any form, CF cards, USB flash drives or any external drives. This makes only embedded systems and devices like phones with direct NAND/NOR management AFAICS.