A Pi is surely a reliable piece compared to let's say a computer desktop. Considering it's only doing the job of running a script and serving a web page or two, it should be. Still, it's not a controller, it is a computer with the ability to act as one. Does that make it a better choice, or does that make it a compromise? Most people who do this work for a living would say the latter.The uptime for the Pi last time before the PSU flaked out was 41 days. My Pi media centre is usually up for months. There were reliability problems with early Pis, but that is no longer an issue.
I have tried to make the code "multi-chamber" compatible. You can specify an .ini file at startup which contains a different set of GPIOs for the relays and a different set of addresses for the temperature sensors. So, you can do multi-chamber by running several instances of the software on the same Pi.
However, with the Pi Zero being so cheap you could run everything on one of those (web server, data logger, controller) and just have one Pi Zero for each chamber. All on wifi, no BT required. No central controller required.
I would not want to run multiple chambers from one device, because that is a single point of failure for X controlled points. Using a microcontroller per controlled device and then combining the information reduces that risk by quite a bit.
Running multiple Pi means I have multiple web servers to "visit" (and to administer), I'd prefer to have one.
Now combining that idea; using Pi Zero for each chamber and then using a single Pi as a hub to collect all of the information, maybe that has some merit. It's certainly cost effective. You'd have to extend the Python to be a web service rather than a local device (I think you have stubs in there to do that?).
Not arguing, just kicking around ideas.