Then how come it did work before? BTRFS as used in DSM is not particularly more memory intensive than EXT4 (which is why it did work before).

It works, but there is a risk (exacerbated if you use other features) that the device will become unstable. I believe depending on features used in btrfs it can use considerably more RAM for caching filesystem structures. While this cache can be freed, performance drops as the system need to retrieve this from the disk again. Considering reliability / reputation / performance it makes sense to not allow it as a supported configuration. However many vendors do this softly, and not as a hard lock. i.e. we won't let you create it (or we do and warn you), but if you complain / log a support ticket it will be ignored until you can show it on a supported configuration.

Synology can easily allow access to the volume. I would think the smartest decision when removing a feature (even a feature that was never intended to exist) to instead make the unit at least mount the volumes as read-only and allow the data to be exported to the network / cloud / USB drive.

I think it's RAM, not CPU. My DS418 has 2GB of RAM and an ARM CPU and supports BTRFS.

Compare that to the 4GB of a Raspberry Pi 400.