There may not be a justification "security wise", but there are other design considerations which are worth exploring. In my opinion, the biggest advantage of using OAuth is that you abstract the authentication method from the various systems required authentication/authorisation (this is something tylerl was describing).
As an example: you start off with one service which you authenticate against using JSON username/password. Everything's working well, but you decide to introduce another service which provides slightly different functionality. The new service also accepts username and password via JSON.
At some point, somebody points out to you that MD5 is broken, or you're not salting your passwords correctly. No problem - you can fix that. But you have to fix it in both (all) of your services which are performing authentication... How many of those do you have? Do you actually know where they all are? How can you deploy the change to all of the services at the same time?
By performing authentication against an Authorization Server, as in OAuth 2.0, you partially remove this dependency. You can easily change the authentication mechanisms within this server, and as long as your services continue to accept OAuth tokens, you have no problems.
The other important point is that OAuth is a standard pattern. When it comes to authentication, adopting standard patterns are always better than implementing your own authentication schemes. Furthermore, if you wanted to expose your services via the Internet at some point, the fact that they accept OAuth access tokens would make the whole process a lot easier.