From the docs, there's rootwait and rootdelay which helps in some cases.
It's useful when the device needs more time to initialize properly.
Large mechanical drives and that sort of thing.
For sdcards I'm not sure how much it helps, but I do know they are unreliable in production.

This device (eeepc 1025C) is pretty crappy overall, and it does not have a built-in SD connection to /dev/mmcblk. There is a slot for an SD card, but it connects via USB as you have seen. I removed the card from there and put it into a SD card reader which I plugged into a USB port, but it shows the same delays when booting. The card reader shows up as idVendor=0781 and idProduct=a7a8, so at least that is different. Too bad, that sounded like a promising place to look.

I use "-w 10" with mkinitrd, which adds a 10 second wait for drives to get ready. That sounds like it should be enough for initialization (at least it is for the 5.15 and older kernels). The problems do seem to crop up about the time the SD card is probed, so I wouldn't be surprised if it does have something to do with that.

I'm not using kernels with initrd support, but I do know initrd can't wait for rootfs if your initrd image is on rootfs.
If your bootloader is on another drive, then you could add rootdelay there, and it'd wait for rootfs.
Anyway, what is suspicious is that @0.122498 it's decided not to use MMCONFIG but @0.168431 it somehow changed its mind.
And regardless, your real timeout's @190.867299
Which may point at eudev binary, eudev hwdb, or eudev rules as a cause of the delay.
May also point at faulty card reader, faulty card, or faulty kernel module.

I updated the system on the weekend and it boots normally now. I don't see any updates to mkinitrd or eudev, so I have to assume that the new kernel fixed things. I would have liked to have seen the difference between the old and new kernel config files, but the old one was removed when the package was updated. Oh well. Anyway, the problem appears to be solved.