When do we need to change the state of a push down automata?
As Renato suggests, you never need to change state in a PDA. Even without useing a CFG as an intermediate, we can take a PDA and construct another that does the same job with using only a single state (a proof can be found here). The basic trick is to use the tape alphabet to encode the state of the original machine (and part of the transition). This works perfectly well for both deterministic and non-deterministic PDAs.

This is a little unsatisfying however, as a single state machine with a huge tape alphabet is not a particularly natural way to design a PDA (at least if you're like most humans I have met, there might be someone who thinks that way, if so, well done[!|?]). One intuitive reason to change state is as you suggest, because the machine is meant to be doing something different. Analogously to how we would talk about what we as humans are doing, for example, when we're working. We might break a task into steps, and perform them in a "sensible" sequence. The idea is the same with designing PDAs, break the recognition task into a series of steps, and change state when you move from one step to another.

As an example, consider the canonical non-regular context free language $\{a^{n}b^{n}\mid n\in\mathbb{N}\}$. In processing this language, we might have a starting state, a state for processing $a$s, a state for processing $b$s and an accept state. We move from the start state to the "$a$" state by pushing a botoom-of-the-stack symbol, then process the $a$s (probably by pushing a symbol for each $a$), then move to the "$b$" state using a $\varepsilon$-transistion, process the $b$s (popping off the symbols we put on for the $a$s), then move to the accept state if we have reached the end of the input and can see the bottom-of-the-stack symbol.

This is not the only way to build a PDA for this language, but the changing of states has a natural, intuitive meaning that is useful to us as humans in the design process (and for others trying to understand or implement it).

Unfortunately there's no simple "this is when to change states" rule. As the single state example shows, you can design things in a very arcane, incomprehensible manner, but they are still correct. Like a number of things in maths, CS and programming, you really have to just practice it a bit, look at other solutions and develop your own intuition. It is in many ways like programming (funnily enough) - there's lots of ways to solve a problem, only some are good ways, but there is at best only general guidelines to what to do when and where.