Recognizing loops in computation on LBA
If I understand the question correctly, you are asking why are we bounding the number of configurations, rather than checking for a repeating configuration?

Well, clearly these are equivalent in the sense that in both ways you will detect a repeating configuration.

In the first method, we use the pigeonhole principle, and we say that if we passed a certain number of configurations, then there must be a repetition, since in an LBA the number of configurations is bounded (after fixing the input). In order to detect this, we must keep a counter of the number of configurations we passed. The advantage of this method is that keeping the counter is simple (it takes linear space). The disadvantage is that the loop may have occurred early in the run, and we will only detect it late (after an exponential number of steps). 

In the second method, we need to track the configurations we have seen so far, and compare every new configuration to all the configurations we have already seen. The advantage is clear- we will detect the loop immediately when it is caused. But the disadvantage is huge - we need to track all the configurations - this may take exponential space, and in every step we need to compare all the configurations to the current one. 

Essentially, the first method solves $A$ in PSPACE, whereas the second solves it in EXPSPACE, so we usually take the first.