To serve different content, proper content negotiation should be used. Base content type on some custom header instead of
Accept request header makes things more complex than they need to be. However, you're right that this could be one of the reasons, implemented by a person who was unfamiliar with HTTP.
Another possibility would be to make the system more secure. Although this is a wrong way to secure the system (since the restriction can easily be circumvented by the client adding the requested header), it prevents “simplistic bots from testing out user/password combinations,” as stated by amon.
A third possibility would be to make sure login requests are always done through AJAX (for some cryptic reasons). This way, if the client-side code is changed to do ordinary POST to login, it will be quickly possible to figure out that something went wrong, since the login won't work any longer.
None of those reasons is strong enough to justify the use of the custom header:
Content negotiation should be done using standard HTTP mechanism. There is no need to reinvent the wheel just to make the maintenance more difficult than it needs to be.
Security should be handled properly, using standard security procedures. The subject is ways too large to be described in an answer, so see Security.SE and the books on the subject, if interested.