If you read that, you'll notice that it uses a generous definition of sprite multiplexing, claiming the NES has hardware support for multiplexing on the grounds that it supports 64 sprites total in OAM despite only being able to display 8 of them per scanline.
If you take the NES sprite limit as 8, being the number of sprites the NES can display on a line, this makes some sense. If you take the NES sprite limit as 64 (the size of OAM), multiplexing would have to mean displaying more than 64 sprites onscreen, and I don't think the NES can do that; it certainly has no official hardware support for it.
...
In the context of the SNES, what I think we
should mean by multiplexing is the latter - displaying more than 128 sprites by reassigning OAM entries as the screen is drawn. We already know the SNES can display more than 32 sprites onscreen simply by making sure they're at different vertical coordinates, or by shuffling OAM so they flicker instead of just not showing up; that's not an interesting question. The interesting question is: can we make the SNES accept new OAM data during active display?
So far, I don't think anyone has done it. I've been meaning to try something, but it's a tad more complicated than the live CGRAM rewrite trick I used to get DMA direct colour working. If it turns out that the DMA has to target OAM with half-dot precision, it may not be possible to do it reliably even if the data goes in, because on some models of SNES the CPU-to-PPU half-dot alignment is set randomly at boot, and DMA auto-aligns on CPU timing. There was a way around this with DMA direct colour, but with OAM I don't see one.
You can't do the obvious thing, which is rewriting OAM during HBlank - at least, not in the general case. You can do that with CGRAM because it isn't being used when no pixels are actually being rendered to video out. You can do it with VRAM if you use forced blank to stop PPU accesses to VRAM during HBlank - but what are those accesses? Sprite graphics. So you can't safely rewrite VRAM unless there happen to be no sprites on the scanline immediately following the forced-blank HBlank, because if there are they will not load properly. And obviously the same is true of rewriting OAM, with the additional complication that it's a lot harder to come up with a scenario where you can guarantee that there are scanlines with no sprites on them in useful areas of the screen if the scenario is such that you're heavily using OAM. (If you
do have a situation where you can guarantee that, yes, I think it's safe to say the SNES can multiplex sprites quite easily.)
otherwise, why even bother with it?
Because there's no other way to trim individual sprites vertically so they don't cross over the screen split.
(Well, there is, but it involves using more sprites and possibly flirting with scanline overload. It takes advantage of the fact that sprite-sprite priority and sprite-BG priority are independent, so that sprite A can be above sprite B even if sprite A is below BG1 and sprite B is above BG1 - in this case, sprite B will have a sprite-A-shaped hole cut in it and BG1 will show through. The solution Super Mario Kart settled on is arguably more elegant.)