According to the text

  a glTF asset is represented by:
  * JSON file (.json) containing the node hierarchy, materials, and cameras
  * Binary files (.bin) containing geometry and animations
  * Image files (.jpg, .png, etc.) for textures
  * GLSL text files (.glsl) for GLSL source code for individual stages

See also https://github.com/KhronosGroup/glTF/tree/master/model/duck for an example.

.obj is a horrid format for runtime usage in a game engine. The effort required to parse a non-trivial model will explode your load times on resource constrained systems.

The content pipeline that I implemented for our game engine always converted .obj files into a binary format that is trivial to load at runtime. In an ideal world (i.e. not Android), your binary format is one that you can simply mmap into your process and then at worst "loading" consists of copying this memory and doing some pointer fixups.

Yes, and that's why one can wonder why they once again chose JSON for part of this new "web standard". Text based data formats should die.

From TFA:

> There are industry-standard interchange formats, namely COLLADA, that allow sharing assets between modeling tools and within the content pipeline in general. However, these formats are not optimized for size or runtime use and neither are modeling-tool-specific formats. At runtime, an application wishing to render an asset needs to do a significant amount of processing to transform the asset's content into data appropriate for the GL APIs.

Yup, but it only supports static geometry. Looks like glTF has animation support.

In "offline" world all we ever use is objs and alembic as of recently. I wonder if alembic is suitable for realtime use.