So using distcc means that all computers using it must be trusted. And that means that using it on "all developers computers to share the load" is good for performance but bad for security.
I'm not sure whether distcc affects reproducible builds?
You could, in any case, have tighter controls on the release builds, which would be done on a CI machine before signing.
(Back when I used distcc we didn't distribute across the dev machines, we had an entire build farm of two racks of 2U servers!)
I would not generalise so quickly. Is every computer compromised in the internet if one is compromised?
No. It highly depends on the trust between those machines and whether they share similar services with critical vulnerabilities. Only then, they might be compromised together.
But the world has evolved and not everyone anymore bases their total trust and security thinking for "no outside internet connection, we are fine".
Internet is no lan (local area, L2) where computers do indeed typically have more generous policy regarding access between each other.
Think about the windows firewall asking whether you just connected to a work/public/home network
That might've been true 10 years ago and still is in some case but I wouldn't assume that now, far more things run over encryption for example, or have firewall
When the team is bigger or when security is more important, it's important to have a build system where you're confident that no one can subvert the output, and that includes ensuring that very few people can control machines running distccd.
Another way in which it shows its age is that, by default, there are only netblock based restrictions on clients, and connections are over unencrypted TCP by default (last time I looked), although there is an option to use SSH (or I guess Tailscale or similar.)
Granted, if your distcc host gets compromised, the compiled output shouldn't be trusted until the server can be reprovisioned.