I've never heard that, and can't imagine why anyone would think it a problem. I've certainly had projects that required multiple forms per page.
FWIW,
I agree with Hassan. If you want to give your pages multiple functionality you have to be able to use multiple forms. Just look at Amazon, for example. After you have chosen a book/other and it's in your cart you have a form to check out but they also offer selecting more items. Are both things one and the same or are they run by the same form? I hardly think so.
Pepe
POST data is not structured, so while you can use multiple forms on
the same page, there could also be namespace conflicts. The resulting
query string (in case of a conflict) could be really bizarre and prone
to subtle bugs. Not a problem when it's you writing the code or when
the page is stupid-simple. Problem if you are doing complicated stuff
and others might inherit the code.
If you want to see how Amazon implemented their form, Firebug is your
friend.
I'm not trying to convince, just offer a possible explanation 
Yes, you have to be careful with multiple forms on the page to not have duplicate element IDs and whatnot, particularly if you're using JavaScript. However, you can only /submit/ one form at a time, so there should be no problem on the back end.
And I'm not sure what that second sentence means, since POST data isn't delivered as a "query string". Can you clarify?
Well, POST data is actually delivered as-if a hidden query string. So, for a GET request, you have an HTTP QUERY_STRING and for a POST request you have a RAW_POST_DATA. Both are functionally equivalent and neither are scoped.
Look, it can and does work, and there's no reason to believe it will stop any time soon. But why use multiple <form> tags when one will do? Are they posting to different actions? Do they expect to know the contents of fields in the other form? Should the user expect to know the behavior of hitting enter when in one form or the other (can they really tell they are in a different form)?
I'm not a fan, but if there's a clear argument why this is a simplifying practice, I'm all ears.
Well, POST data is actually delivered as-if a hidden query string. So, for a GET request, you have an HTTP QUERY_STRING and for a POST request you have a RAW_POST_DATA. Both are functionally equivalent
Mmm. Well, they both deliver data, so I suppose you could say
that. Angels, pins, tomato, tomahto, whatever
Look, it can and does work, and there's no reason to believe it will stop any time soon. But why use multiple <form> tags when one will do? Are they posting to different actions?
Of course. Why else would you do it?
Do they expect to know the contents of fields in the other form?
Not in any example I've developed (or seen).
Should the user expect to know the behavior of hitting enter when in one form or the other (can they really tell they are in a different form)?
If they don't understand what's going on, someone's done a crappy
job of UX design, but that applies to so many things
