The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.
Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.
I don’t see how Homebrew would be similar to AUR.
Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks.
Anytime a Homebrew user installs a formula from homebrew-core and the system starts to (re-)compile, almost certainly something is wrong.
EDIT: whoops, that was incorrect. It's actually `brew update` that is run automatically, which updates Homebrew itself plus all of its formulae. However, I think often the effect can't be similar. If formulae are updated, and the new package you're trying to install shares a dependency with other packages, the dependency will be automatically updated as part of the install process. I'm not sure if this can also trigger an update of an existing leaf package though.
Add this to your .zshrc or equivalent (f for fast):
alias brewf="HOMEBREW_NO_AUTO_UPDATE=1 brew"
Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.