Install writes to the repository, not to the cluster
The install command does not mean "install now". It means "record that this should exist". ArgoCD does the installing, and that changes the meaning of every other operation.
The command that installs an application does not install anything into the cluster. It writes the desired state into the project repository, commits the change and pushes the canonical GitOps source. ArgoCD then applies that state.
The difference looks formal and changes almost everything.
What changes
An application removed from the cluster by hand comes back. The owner of the state is the repository, not the last command someone ran. The cluster continuously converges to the description.
Installation becomes reversible in an understandable way: a rollback is a reverted commit, not a search for what exactly the command did.
Review becomes possible. Adding an application is a diff that can be read and discussed before it is applied.
History appears on its own. The question “when did we get this service and who installed it” has an answer without a separate inventory system.
What it costs
Installation stops being instant. Between the command and a running application sits a reconciliation cycle, and it takes time.
So the command has a wait mode: when run interactively it waits by default until the state is synced and healthy. For scripts and continuous integration, waiting is turned off with a flag and the timeout is set explicitly.
The default is chosen by how the command is run, not one for everyone: a person at a terminal almost always wants to wait, a script almost never does.
Why not install directly
Installing straight into the cluster is faster and clearer in the moment. Its problem is that it creates state that is not in the description.
Six months later the cluster runs a set of applications, some installed by the command, some by hand during an incident, some by a colleague who has left the project. The description still looks complete. The mismatch is found when someone tries to reproduce the environment.
Writing to the repository makes the mismatch impossible by construction: if an application is not in the repository, it should not be in the cluster, and the other way round.
A local source without an external server
The usual objection to this rule is that not everyone has their own Git server.
A local GitOps run solves this. If the given folder is empty, the tool creates the working tree, a local remote repository inside the project, the source file, the first commit and the push.
This is not a way around GitOps and not a fallback. It is the same canonical source, just located locally, with the same behaviour and the same guarantees as with an external server. The source can later be switched to an external one without changing how you work.
What stays manual
The decision about what to install. The tool does not propose a set of applications and does not silently create dependencies. The catalogue has dependency metadata, but the choice stays with a person.
The reason is the same as everywhere else: defaults for what an infrastructure contains are a bad idea, because nobody revisits them later.