I see no valid reason to have the RAM decoded at all addresses other than that specific to ROM or I/O. I especially don't think page 0 and page 1 should no be scattered across the addresses.
The SYM-2 should not do anything different than the SYM-1 without purpose. If the purpose was to to make it easy to crash the system, poorly addressed locations would make it more likely. I'd like to see some documentation on the SYM-2 but have only found documentation for the SYM-1. There is nothing about scattering page 0 on purpose. It is properly decoded.
I'm a little unclear why partial decoding is going to "make it easy to crash the system"? I mean, obviously there are downsides to the practice; on any computer that has an available bus it wastes address space that could be used for expansion, and it also has the potential to create backwards compatibility issues if programmers elect to use a mirror in place of the "official" address for whatever reason and you later revise the hardware to impose fuller decoding later. (I think in theory this applies to, say, the Commodore PET, because it uses *very* partial decoding for its I/O area that not only allows every chip to be addressed at multiple addresses it allows multiple chips to be activated at once, and CRTC and non-CRTC PETs end up with a different total bitmap of shadow'ed addresses...)...
But in a vacuum, if you're talking about a simple single-board fixed configuration machine with X amount of RAM it seems like a reasonable expectation that any software that inadvertently runs outside of the valid RAM footprint is going to crash regardless of whether there's a shadow of the real memory or empty space there? That a second copy of the zero page exists one byte past the end of real memory is only going to be a problem if you write software that's manipulating some data structure in high memory and because of poor bounds checking you keep writing past the end of the object?
Anyway, this is all theoretical, really; in this particular case this sure reads like this (particular?) SYM2 computer has a hardware bug. Scanning the manual of the SYM1 I agree, it does read like its 4K of onboard RAM sockets are fully decoded. It seems like there's almost no documentation out there for this beast(*) but what there is claims it should be compatible with hardware add-ons with its predecessor so by all means fix it.
(* Have you managed to find *any* manuals for the SYM2? I'm guessing this must have come out near the end of the company's life. Bitsavers has nothing but tumbleweeds...)
On the Sinclair MK14 computer, things were partially decoded permanently. This resulted in some programmers using different addresses for things like the keyboard and display.
On the other end of the sophistication spectrum I know a number of Macintosh models used really sloppy decoding internally, with shadows of RAM and ROM all over the place. It's even my vague recollection that some '030/'040 models with multiple SIMM banks actually relied on using the CPU's built-in MMU to assemble linear memory address space because the socket banks were permanently separated by fixed offsets that would be filled with blocks of repeated memory when used with less-than-maximum-size SIMMs. (The thinking being the MMU was there, why not use it and save a few transistors in the memory controller?)
The TRS-80 Model I/III annoyingly wastes an entire 1K of address space for keyboard scanning; it *should* "only" waste 256 bytes, but they didn't fully decode the 1K boundary they dropped it into. I've been sketching out a TRS-80 semi-clone and I'm wondering how much incompatibility it'd cause if I cut down that window; I gather there is at least some software that's pretty careless about treating the entire block as free game for scanning, not just the bottom 1/4k.