I can't think of a scenario where this would happen to someone who doesn't know what they're doing. Everyone with a "standard" guide-based setup won't ever have anything other than Luma as boot.firm (except maybe SafeB9SInstaller if updating B9S, which doesn't chainload anywhere anyway). If you are in a scenario where you're booting Luma from SD from a location other than as boot.firm, you're probably more likely to not have boot.firm in the first place, but more importantly you would be able to recognize if something is going weird (not to mention booting without SD with fastboot3DS would bring up its configuration IIRC rather than power off (now with notification LED colour) like B9S does).
SD writes aren't really relevant here. Luma is already known to sometimes have conflicting config if you're switching between old and new versions (maybe even forks if they have different config?), which has nothing to do with the CTRNAND copy feature. The CTRNAND writes are IMO negligible compared to both what the 3DS writes and to what a power user would be writing.
As far as I can tell, Luma will only attempt to write itself
once per version (not entirely sure in what way forks are implicated this, but it seems to be implied
here that if you run base Luma first then forks will not attempt to write boot.firm to CTRNAND).
---
The feature is ultimately to ensure that each and every person is able to boot on CTRNAND. If you're a casual fork user, you probably don't care what CTRNAND boot.firm is - the critical factor is whether your 3DS can boot if your SD failed for some reason, and whether you use a fork or not doesn't really matter in that case.
I don't personally take issue with a fork like this one removing this feature because 99% of the time the people that the feature targets (people that don't really know what they're doing) will only ever run and use base Luma (or maybe 3GX Luma, but either way they'd have a working Luma as boot.firm on CTRNAND). But the portrayal of the feature as generally anti-user bugs me a bit. An inconvenience to very specific types of power users, maybe (if the forks end up fighting each other to make themselves CTRNAND boot.firm).