That's a great question, and I think the answer is that it's not necessarily better. It most likely depends on your use-case, whether or not you're starting a product/service from scratch or not, and how much control you need in resolvers.
I think a key constraint of GraphQL JS is that the
buildSchema utility will not let you define proper resolvers for Union/Interface types that you define in the GraphQL Language. There are definitely ways around this limitation, and Apollo is doing a great job of demonstrating that. In Apollo-related projects they actually have you define your schema in the GraphQL Language, and then you define the resolvers separately, much like you described above.
I think this approach is awesome, and can make things incredibly simple to get up and running so if that's what you want to do definitely go for it. From another perspective, if you're creating a GraphQL Schema and you want to implement a middleware-esque pattern on resolvers then you might want more fine-grained control of your schema. You might also want to leverage existing JS-tools that you have, such as codemods, in order to maintain your codebase and bring it along with you as your product/service/company grows.
At a high level, I think that covers why you might want to use one or the other. I think they're both great strategies, and one can make whichever approach they choose work for their use case. Hope that helps!