Very weird that you have such an strong opinion of having some self written deploy script over a argocd setup.
ArgoCD is super easy to setup, has a declarative setup and is a great platform tool.
I introduced it to big systems and i really can't imagine how we would struggle if we would deploy those infra components with some bash scripts.
Could you be more specific?
Like assume you have some monitoring stack (kube-stack or grafana etc.) and either as a helm chart or as something else: What do you do when a CRD needs to be replaced? You write it in your deploy.sh script through some bash magic? Handling error cases in there?
What do you do when you want to see what you have deployed? Like checking if your test setup is rolled back? You always use kubectl to check some helm values? Or do you always annotate all pods with git commits which you then c&p?
A basic ArgoCD declarative setup takes perhaps a few hours if you do it for the first time, than you can give teams access to namespaces, they have log access, exec access if you provide a platform that is, in my opinion, quite a big advantage over just letting them use kubectl. Most developers i know do struggle with kubectl.
And for my own infra ( i also even setup argocd at home ) the dev cycle is much faster for me.
What "crappy cloud architecture" problem are you talking about specificly argocd apparently solves?
How do you test components? Like we have a test cluster and everyone uses argocd to just switch to a dev branch for a few days while testing. This works really well and you can switch back to main in argocd. And due to Argocd App Def you can even see all apps out of sync due to testing.