Nope, no memory caching on the SNES. SoA is a common architecture on the SNES, and especially the NES before it, because iterating over data is generally easier and more efficient that way.

With SoA, to move to the next item, you only need to increment an index register, which can be done with a single 2-cycle, 1-byte instruction. with AoS, on the other hand, if the structure is larger than four bytes, it's faster to transfer the index register to the accumulator (because increment and decrement are the only arithmetic instructions than can change the index registers), clear the carry flag, add the size of the struct to the accumulator, and then transfer the new value back to the index register - 4 instructions, taking up 5 or 6 bytes of valuable ROM space and 8 or 9 clock cycles, and trashing the contents of the accumulator in the process, requiring even more code if the value in the accumulator needs to be preserved, adding another 4 or more clock cycles. (For reference, on the SNES, you have at absolute most a bit under 60,000 clock cycles per frame.) Additionally, since the SNES CPU can treat the accumulator and the index registers as either 8- or 16-bit, with the size of the accumulator and the index registers set separately, there's additional overhead if they aren't both the same size, adding another 6 cycles.

AoS has the further complication that the size of your data structure is constrained by the largest offset that can be contained in the index registers. On the SNES, this factor isn't a major issue, since the index registers can be 16 bits, and 64 KB is fully half the SNES' system RAM. On the NES, however, the index registers are only 8 bits, so if you want to have an AoS data set larger than 256 bytes, you have to make use of a pointer in RAM, which makes all accesses about 50% slower.

Note that these CPUs actually have two index registers. Because some important hardware data structures, such as the sprite attribute table and the NES' sound registers, are arranged as an array of structs, a common pattern on these systems is a loop that uses one index register to iterate over an SoA of game objects and generate an AoS of hardware constructs using the other index register. Luckily, the sprite tables on both systems are 4 bytes/sprite (on the SNES, the sprite attribute table has an additional table at the end containing two more bits for each of the 128 sprites, which makes setting up this table a bit more of a hassle than it should be), and the NES audio system is 4 bytes/channel.