Testing in a loop is a best practice when you're testing for things that require a lot of repetitive testing to come up with a positive or negative result. There is no One Right Answer to Every Situation, but there is usually One Right Answer to a Specific Situation. Each scenario has to be examined on a case-by-case basis.
When you're just testing the form to make sure you can log in, there's really no difference if you do it once or a thousand times. Either it works or it doesn't. This is what people mean when they say "insanity is doing the same thing over and over and expecting a different result." If you're testing something that's ultimately idempotent, test it once. If there are two possible branches (e.g. login and failure), test each one.
Sometimes you're out to make sure that the system is imposing reasonable limits or performs well under stress. You should probably be doing this. In those cases, it makes sense to log in a thousand times to see what happens. There's two particular categories here I can think of immediately.
Perhaps a user is only allowed to log in 5 times an hour, perhaps because it would otherwise create too many sessions and bog down the authentication server. Or whatever the case may be. Run the test and try to log in 6 times immediately. Did it work? Limits testing is important when there are limits to test. Or maybe a user is supposed to be locked out after 5 failed attempts. Are they? Test the boundaries of your system to make sure that they are, in fact, boundaries.
Testing Resource Use
Some frameworks, libraries, languages, etc can leak resources over time. The two main resources that are likely to leak are memory and event handlers, although others are certainly possible, and if you know about any potential leaks, you should write unit tests once they're fixed as part of a regression test suite.
Memory leaks will eventually cause the application to consume enormous amounts of memory, and may result in the OS slowing down to fulfill the requests and/or terminate the program. If a person logs in three times, then, in theory, memory usage should be more or less the same than if they logged in 300 times. This can be especially important in a browser, as many users only close their browsers once every few months; the leaks actually could cause a crash.
Event handlers can also leak, in a sense; the same event gets registered over and over to a single element, causing duplicated (possibly harmful) behavior, and as they stack up, eventually the CPU will be pegged simply trying to service all the events, making it seem as if your app is frozen, even if it doesn't cause any other obviously harmful effects, like saving a file multiple times. In this case, it makes perfect since to loop a thousand times and check the resulting event handlers. There should be approximately the same number after the first login as the thousandth.
At the end of the day, use common sense, and think through the logic. Test no more than you need to, but definitely test as least as much as you need to. There is a balance, and using loops, or not, is a balance between compile/deployment times and catching otherwise obscure errors.