I think there a few techniques getting lumped under one banner, which is cause multiple parties to get confused and cross point each
Having Entity type X = RAM address Y to me is Static Allocation. Its means you only ever have one active at one time and allocation/update is super fast. So you might have clones in the Entity type table to handle having more than one of the same object. Mario Kart Battle for example, 4 players and 3 balloons, fixed alloc it why bother doing anything else
Having Spawn Entity X @ Sprite Y to me is Fixed Allocation. This is when you walk though your data structure in the level editor and work out where each entity will have its sprites. For example if I was porting Super Mario Bros to the C64, I would use this method to spawn enemies. As you can only walk left and hence the trigger order and number of entities on screen is mostly fixed and known at all points.Allowing me to handle things that will walk off vs something like a hammer bros that is fixed to an area but needs 2 extra for hammers. So I can just put the sprite number in the level data. Zero sorting, zero hunting for allocation and my level editor tool can check and flag instances where I "sprite out". Eats some RAM though as the level data is now larger.
Having an Entity set to a "slot" at allocation by the code, this is Bucket Allocation. The idea is you divide your sprites into groups, 6 sprites for example. Then when you spawn an entity you request the next free group, or next free run of groups if you need n. This speeds up allocation and hunting, and helps combat fragmentation. As you can when you remove one, copy the last sprite into the empty bucket but potentially wastes space, as if you only need 4 sprites you still alloc 6.So you can get the situation where there are enough free sprites but no buckets. You might have different buckets or pools, so bullets will have their allocation, small entities, large entities as needed etc
There are other special cases like Ring Buffer allocation. For example Squid Jump uses a Ring buffer allocate, as the appearance and disappearance are in a fixed order, so I either add at the head or the tail and them remove at the head or the tail ( if you collect a pickup - I just hide the sprite but keep it in the buffer until it is culled as it goes off screen )
As always there are hybrid methods
Bullets being Ring Buffer while main entities are bucket, while special case enemies are Static alloc etc
as rainwarrior says, Sprite cycling is a separate problem, done because you need it, or not if you don't. you can alloc your OAM one way as per above but not copy it that way to OAM RAM. So you can add an extra step the shuffle the OAM before DMA eats more clocks, but then having each entity no have to look up where and what order its sprites are in every frame might save you more in the long run. Depends on what your game needs. For example you could store the OAM stripped, so 64 X, 64 Y, 64 Tile, 64 Attribute this way a ent can modify each of them with a single ,x and no + 4 maths to get to the next. Then your code does a LSFR to step through all 64 in a random order as you copy the stripped to OAM format. Or you use a LSFR to change the "bucket" order when you copy etc etc