My theory is that it's because of the new game-specific-moveset saving mechanic and how it's stored on HOME servers + tied to the HOME tracker value...
I guess you could test this in reality by hacking mons to have the same HOME tracker value from within SWSH and BDSP and seeing what happens.
Just to confirm, I did exactly this, and took it a step further to verify just how poorly their checks are handled for clones with the same tracker value.
Setup:
SWSH Kirlia -> HOME (gained tracker value) -> SWSH -> cloned w/ tracker + evolved to Gallade and Gardevoir
Test 1 (Different Species ID, same Evolution Stage):
Clone Gallade -> HOME -> BDSP (gained BDSP moveset) -> HOME (BDSP moveset stored in HOME) -> SWSH
Clone Gardevoir -> HOME -> BDSP, Gardevoir gains Gallade's moveset in BDSP
Test 2: (Different Species ID, impossible reversion of Evolution Stage)
Gardevoir with Gallade's moveset in BDSP -> HOME (BDSP moveset stored in HOME again) -> SWSH
De-evolved clone SWSH Kirlia -> HOME -> BDSP, Kirlia gains Gallade's moveset in BDSP
It appears that not only do they
not reassign the tracker value if
both clones are not present in HOME at the same moment, they also do not check if the Species ID matches what HOME "previously saw enter from another game".
In the hypothetical scenario, you could even clone a Nincada and have it gain the moveset of a Shedinja or Ninjask.
If the same tracker value is found on Pokémon with certain immutable values changed, say altering the IVs, PID, etc. then it will indeed reassign the tracker values, but this test at the very least confirms it doesn't check for otherwise identical clones in the same "family tree".
As long as
those clones with the same tracker value "take turns" entering HOME, and only enter from the game it "expects that Pokémon to enter HOME from", it literally doesn't care and will treat them all as the same Pokémon.
It only reassigns the tracker value and starts treating them as distinct individuals with their own copy of the HOME-stored data if multiple copies of the Pokémon with the same tracker are present in HOME at the same time.
Edit: I performed further tests and
I do not believe this is the reason Nincada is blocked from moving between games, as Shedinja appears to instantly receive a new tracker the first time it enters HOME after evolving.
I would theorize it's more likely a redundant check to prevent you from bypassing BDSP's dupe checker with natural clones, because they already have a check in place to prevent this issue with Nincada that is completely separate from it being blocked from transferring between games.
If the last time HOME "saw" that tracker value was on a Nincada, and a Shedinja with that tracker enters HOME, it's instantly given a new tracker, (this happens when entering HOME, it's possible to observe HOME data via RAM read, and the tracker changes
before it re-enters SWSH or BDSP). The matching Ninjask keeps the old Nincada tracker, and the Shedinja's new tracker remains static after the reassignment. The Shedinja's new tracker is issued even if the matching Ninjask does not enter HOME at the same time.