I don't mean this sarcastically at all, I am genuinely curious about what you said, as you seem to know a lot more than I do, please clarify if I am wrong.
Hey, it seems
you would know more than I do! You modded The Witcher 3? You mod videogames! That's already an Awesome™ skill tier to have.
My field is not videogames programming so I don't really know the specifics of how things are done in the industry, buy my fields
do are computer systems analysis and integration, so I was taught the thought and the tools behind how to make systems work, work correctly and work fast.
(Basically my job description is to tell my coworkers "you shouldn't do / have done that" but people seem to not like it when I put it that way)
Come to your points:
I'm no animator, but from my limited experience/understanding. wouldn't it just be a matter of adjusting the coordinates of the particle nodes to match those of the camera?
The camera moves statically during attacks meaning that their location is not a dynamic variable within the engine, rather it is simply unique to every Pokémon. Therefore, it does not seem like a hardware or labor restrictive problem.
If the attack animations are hardprints (ie.: solid animations without handleable nodes), that might serve a good base, since at most you only need to move the model of the Pokémon within the scenario to find a good fit, assuming there is one.
Unfortunately the problem of calculating and storing the necessary adjustments per user per target is costlier on aggregated time (and processing) than the alternative of eg.: zooming the camera out to a distance where the mismatch is not noticeable, and since the net effect of that simplest solution is that both Pokémon would look smaller and/or less focused during the attack, I guess it was tested and deemed not worth the shot... let's remember the 3DS has an impressive resolution of 240p; that's less than the original Play Station Portable and
much less than the SNES's advanced resolution modes.
The Switch, on the other hand, should have no excuse wrt the ability to stretch, compose or transform animations, or retrace the camera and test obstructions in 3D, so in this console even if the animations were hardprints the issue should be easily solvable, even by preoptimizing and storing the precomputed paths and tuples on disk.
In the end, however, I should be the one defering to you for an analysis of the feasibility of any of those implementations.
Based on my experience modding The Witcher 3, that game has far more unique animations, and a fully user controlled 3D camera as well, and this all from a studio with far fewer potential resources than GF. From a hardware perspective, the 3DS is capable than far, far more than what the Pokémon games utilize, and the switch even more so.
I've heard a number of times the argument that in theory GF should be a studio with unlimited resources - I mean, Pokémon does literally print money. I'm not sure how true that is but certainly the hiring process in GF has resulted in a set of workers that either don't have the time or are simply not capable of performing basic optimization analysis on the hardware implementation that they could take advantage of.
At the same time however, I wouldn't sell the abilities of the 3DS too high. In terms of pure execution capability it is a console less powerful than the N64 and the Play Station Portable, and the hardware comes already gimped in a number of ways including a too low baseline for the second processor, no direct USB data bus, horribad filesystem for on-card storage (the same as Windows 95!), and an inefficient data bus for the touchscreen.
As a relevant data point: when the homebrew scene for the 3DS was still growing the beard, there was a long time during which
playable speed SNES emulation was thought to be impossible even by the people who had implemented other similar emulators before, and even today AFAIK there is only one emulator offering at or above native playable speed. While I don't have that much understanding I'd surmise much of the limitations were due to GPU processing and rendering. Meanwhile both SSE2-tier desktops and the PSP have enjoyed near-native playable speed N64 emulation for a while.