I think there are some reasonable arguments for or against, and i'd say technology also plays a role in the decision.
One could argue having a separate login "page" enables the use of "Directory Security". Generally anyone can see the login "page", but only authenticated users can view the application "page"'s and it's "directory". Route's can also be locked down, where /Account/ is different than /App/ and each has it's own security "profile".
Also, if you're using a SPA approach and you're mixing authentication with application experience the logic could get convoluted. Instead of assuming the user is "logged in because they're here", you have to constantly check their authentication status and ask "should this user be here".
Also, the login page is generally on the consumer facing site.. you go to www.yourapp.com and it has some about info, contact, support, etc.. and a "login" page.. from the login page, after authentication, you could redirect to a whole host of targets..
The reason i keep a separate login page, and why I actually have an entirely different app for my "consumer facing" site is because i can expose very little to the unauthenticated. By chance some moron starts banging on my login page, i don’t want that to affect the app side of things.. even if the login is only doing a simple auth lookup.. it kind of helps me keep the bozo's from affecting my users experience.. Worst case, my consumer site goes down and no one can login, but at least the logged in users wont know and their experience wont start slowing.. I'm not saying that's the bullet proof choice.. but at least i've isolated the risk to the unauthenticated area..