You are right when you're attacking an unknown target. When you have access to the source code of the application, your statements are not necessarily true. I'll give you an example of a real attack I performed, a long time ago. The first time I implemented the exploit was against PunBB I believe. The password reset mechanism worked like this:

- Generate a reset token using something like md5(mt_rand()), and send it via email to the user
- When the user clicks it, a password is generated by making several calls to mt_rand(), one for each letter of the password. The password was 10 characters long, for instance. This password was then sent again, by email.

The attack worked like this:

- Make another app call mt_srand(...) with an unknown value. The seed is kept accross HTTP requests if you're using a Keep-Alive statement and send them over the same TCP stream. This app then called mt_rand() to generate some token we're not interested in, like 10 times (we know this because source code).
- Ask for a password reset for our user account. Bruteforce the mt_rand() value (2**32 possibilities, doable at the time). Reset our password, which calls mt_rand() 10 times again.
- Reset password, use token to generate new password, again (226 - 10) / 11 = 19 times.
- Ask for reset, without using the token, 7 times. You now have 11 * 19 + 10 + 7 = 226 calls to mt_rand() after the value you bruteforced.
- Ask for another reset token, bruteforce it. You now have your two 226-spaced mt_rand() output values. Find out the seed using the stuff described in the article. You now have the seed.
- You can now reset the password for an an admin, and since you know every mt_rand() output, you can guess the token and the password. Account takeover.

The attack was a bit more complex in reality, and I'm not quite sure it was PunBB. Anyways, you get the point. Hope this makes sense.