1. This tightly couples the service to the view. Changes in the view and/or service will potentially result in nasty surprises and spaghetti code. For instance, what happens if the business processes change one day and "login" needs to return "logged in but email address unconfirmed"? You want the rules to deal with that scenario confined to a LoginController, not scattered around through each view (consider: an omnipresent login box view vs. a login/signup form view used when a user performs an action that potentially requires login, e.g. "Checkout")

2. In reality, this simple sample obscures what happens in the real world when you add an input for the user key & password:

a. you will need to pass the parameters to the auth service. At that point hopefully you will won't do anything crazy and will simply e.g. bind the user key & password to $scope properties, and pass the scope properties through to the auth service.

b. As stated in (1), your login & logout controller functions need to consider the result of their auth calls and map that result back to a meaningful state for the view -- in the simplest case, it'll just be "logged in" or "logged out", but it can also be e.g. "logged in but email address unconfirmed", which could require a message to be displayed to the user. The best place for this state is again a $scope property.

So, in practice you would just use a $scope.loggedIn or $scope.user property maintained by the controller login() and logout() functions to resolve this issue.