What is the benefit of separating relationships and attributes in the JSON API specification (jsonapi.org)?

Question

API

Hey! We are thinking about how to make SPA interaction with the backend, we are looking towards jsonapi.org - but already our hands are reaching out to tighten it up for ourselves. Let me remind you that according to the specification, the object ("resource object") should look like this:

{
  "type": "article",
  "id": "1",
  "attributes": {
    "title": "Rails is Omakase"
  },
  "relationships": {
    "author": {
      "data": { "type": "user", "id": "9" }
      // здесь еще может быть опциональный ключ "links"
    }
  }
}

I'm tempted to do this:

{
  "type": "article",
  "id": "1",
  "attributes": {
    "title": "Rails is Omakase",
    "author": "9"
  }
}

Because I just coded such a serialization on the backend, and now I need to disenchant it back into a flat object in JS =)
The client code already has information about relationships, that is, js knows what articlebelongs_to authorand what authorit is user.
It is clear that the variant from the specification is more self-documenting, but for the internal API this does not seem to be so important.
The type property is also lost, but I can’t immediately figure out when it is necessary to know the type for communication in advance (if there can be several different ones in the collection).
What am I missing? Maybe some ready-made tools will not work? Dissuade me =)
PS In general, jsonapi is normal? We do not want to contact Graphql yet.
PS-2 There is on githubhttps://github.com/yury-dymov/json-api-normalizer - but it leaves references as type-value pairs, only removing the extra "data" level. Is there any benefit to storing them exactly like this (I use Vuex)?