I would prefer that we avoid exceptions to coding standards in general. So I don't see a great reason to prefer 2-space indentation over tab indentation for these types of files (*). The 2-spaces rule appears to date back to the introduction of the .editorconfig file into core, and I don't see an explanation of why we prefer this exception:

• https://core.trac.wordpress.org/ticket/26429
• WordPress/wordpress-develop@b21202c

(*) Granted this does make sense for package.json because npm will pretty much force you to use 2-space indentation.

I'm also not sure exactly what composer does here, it appears to have some behavior to preserve existing indentation.

I don't remember why it was included in original .editorconfig /shrug

That said though, it is a current WordPress coding standard to have all .json files use 2 space indentation, so we've two options:

1. Use 2 spaces also here in Gutenberg for .json files
   or
2. Propose a change to WP Core for non-essential .json files to use tabs.

p.s Tabs or spaces are fine based on this: > https://stackoverflow.com/questions/18698738/what-is-the-json-indentation-level-convention

npm will pretty much force you to use 2-space indentation.

'til recently this was the case, but npm 5 will now detect indentation:

Indentation is now detected and preserved for package.json, package-lock.json, and npm-shrinkwrap.json.

http://blog.npmjs.org/post/161081169345/v500

In the case of the Travis configuration, last I checked it fails spectacularly when using tabs, hence the need for two-spacing.

After thinking on this for a bit, I'm leaning towards option 2, removing *.json from .editorconfig here and in core, and as @nylen pointed out above "... prefer that we avoid exceptions to coding standards in general", there's a little code churn for core, but hey we've been given the green light on refactoring code in cases such as this so let's do it...