Well, the thing to understand about the NES is that its graphics system is not just like OpenGL or Photoshop or anything where you can just overlay any old number of images on top of a background bound only by memory and CPU power. There are actually 64 hardware sprites on the NES, either 8x8 or 8x16 pixel blocks of graphic, depending on the mode you set, which can be placed/moved anywhere on the backround and will be drawn correctly 1-bit-masked (by palette color) onto the background assuming that during the scan of a given raster line you haven't hit the end of the 8-deep hardwired check-for-present-sprites logic (8 sprite per scanline limit). It is logically impossible for the NES to show more than 64 "sprites" at once, far fewer if you consider that very few of what are classically termed 'sprites' consist of only one hardware sprite. And because NES is entirely tile-driven, it is next to impossible for anything that isn't a sprite to move independently over a background (this would require direct writing to the tile bank every frame).
So I'm not entirely sure what the "unlimited sprites" option does in emulators that have it, save that there is no logical connection to anything that the hardware should ever be able to be even told to do. My guess is that it works around the per-scanline sprite limit by continuing evaluation as if the graphics chip had all the time in the world to locate and potentially overlap sprite pixels and was consequently built with a 64-deep evaluation. There's an ~off~ chance that the option might also hack the Direct-Memory-Access mode of sprite data updating (on the NES you can either write directly to the position/color/tile data of each sprite individually, or you can format it all in your own block of memory and make a single call to directly copy that whole array to all the sprites at once) to keep shoveling data past where the hardware would normally run out of sprites and allocate more virtual sprites for anything that "looks like" sprite data, which might allow more sprites on game that manage their own list of on-screen objects and dynamically allocate hardware sprites to objects each frame (the reason, I surmise, some games like the ones you mention can clearly have more objects than the NES has sprites for, and usually compensate by continually rotating through which objects don't get drawn), but that's a real stretch.