I guess, this may be related to code overlays, where a new, task specific code segment is loaded from disk or tape to replace an existing one. This was a technique much more advertised for the PET than for any of the later models.

In order for this to work, the new segment has to exactly match the address range of the existing segment, otherwise, the link structure of the BASIC program (which is really a linked list, referencing the memory address of the respective next line) would be lost, and maybe any existing variable data (which follows immediately on top of the BASIC program in memory), as well. It would make sense to adjust for this by including REM statements, which would allow for minor modifications without a need to recreate all the other segments according to a new load address. (Mind that on the PET, all programs were loaded absolutely, just like with a secondary load address of "1" on the later 8-bit systems. Relative loading, i.e. the automatic relocation of BASIC programs, only became a thing with the VIC-20 and its different and also varying BASIC start address. So memory overlays may have been more "natural" to the PET environment. Moreover, PETs – apart from those with the very first ROM version – came with a built-in machine language monitor in ROM [dropped on later Commodore 8-bits to make room for color support], which would have facilitated saving dedicated RAM segments and made this technique more accessible.)

Anyways, the very fact of the removal of these REM statements leading to a corruption of these programs hints at self-modification by one mechanism or another. E.g., a short machine language routine may have been assembled from DATA statements into the locations reserved by a REM statement, which would inevitably result in memory corruption, if these statements would have been removed or changed in length.
(A reason for doing it this way may have been to avoid the Scylla and Charybdis of the growing variable stack on the one side of free memory and the growing string stack from the other, top side, without a need to adjust for varying memory configurations. Notably, this wouldn't have been a thing on the C64, which already came with a full memory complement, but would have been an issue on the PET, which came in configurations of 8K, 16K, or 32K [and, initially, just 4K] of RAM.)


***Edit**, regarding the edit:*

I may add, there is no way that multiple RAM chips may share the same address or may overlap in the address space.
The PET features a continuous memory space for RAM from $0000 up to 32K (the lower half the available 64K address space.) Screen memory is 1K at $8000 and ROM is from $C000 to $FFFF with a gap for IO at $E800–$EFFF. All PETs but the original PET 2001 also feature a ROM slot required vor BASIC 4 at $B000–$BFFF and slots for option ROMs at $9000-$AFFF, thus mapping the entire 64K.

PETs also perform a RAM check at startup to determine the available RAM (which is why you see $AA for any empty, but initialized RAM, while unconnected addresses typically show the high-byte of that address, which is a quirk of the 6502. The original PET 2001 may also show some noise added to the high-nibble of any unconnected addresses.)

(The 6502 is actually quite finicky with the data bus and it's quite difficult to implement bank switching. Which is why the 6510 introduced dedicated port registers at $0000 and $0001.)