Every command reports a number, and zero means it worked. That number is how the shell knows anything, and it is also why a script that ignores it keeps running after something failed. Checking the status is the difference between a wrong result and a loud one.
About 1 min of reading
Branch on a status.
Success path
Before you run it, say out loud what it will print. Then open the answer.
Failure path
Before you run it, say out loud what it will print. Then open the answer.
Read the number
Before you run it, say out loud what it will print. Then open the answer.
Stopping at the first failure is the default you want in a script. Setting that behaviour at the top, or checking after each risky step, is what prevents a script from finishing successfully having done nothing.
grep returns non-zero when nothing matches, which is a normal answer rather than an error. Treating every non-zero as failure turns a legitimate empty result into a crash.
The status of the last command is available immediately, and $? gives it. It is overwritten by the next command, which is why checking happens on the same line or the next one.
cmd && next runs next only if cmd succeeded; cmd || fallback runs on failure. That is a readable branch for one step, and it is the shape most shell scripts should use.
In a pipeline, the status you see is the last command's. A failure in the middle is invisible unless you ask for it, which is why long pipelines need checking stage by stage.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.