I'm impressed by the quality of your command block work - Minecraft doesn't really optimize command blocks very well, so it's honestly impressive that you've been able to execute that task without turning to a Java plugin. I've never seen a spleef-like game automated with this method, and I enjoy where this project is going!

I assume you're having the command blocks emulate a perlin noise map to create the random distribution of blocks broken? Some small recommendations:

If it's at all possible, it may be handy to create a detection state for what blocks have already been removed - a sort of redstone-to-command-block memory system. With the addition of copper bulbs, you can likely do this dustless, which will cut down on lag as redstone dust is extremely laggy. Having this memory system should redivert your command blocks to only attempt to destroy existing blocks, rather than destroying empty spaces and resulting in no map movement.

If at any point in your system you're using hoppers (for example, with hopper clocks), make sure that any hoppers not receiving items from above have a composter above them - this disables the hopper from repeatedly checking for items, reducing lag.

To increase player movement, have it so that any blocks detected between layers are automatically cleared periodically (you could do this by having a repeating command block that doesn't require redstone input set to clear in between layers). This will make it so that there isn't a buildup of blocks on top of layers whenever blocks are falling from higher layers, which can be seen at 3:13 and beyond in the linked video.

To reduce lag, you could have it so that any non-player entities (as fallingblocks are entities) that go 5 blocks beneath the bottom layer are deleted. This will allow the falling animation to continue to look smooth from the players' point of view, while also reducing the amount of physics calculations that minecraft has to do, cutting down on lag.

Best of luck with your project! You're doing great!

cool