« sur quels usages le JSON est-il plus pertinent que le XML et pourquoi ? »
L’article n’est pas du tout orienté comme ça et je m’en tiens à contester ce qui me parait faux.

« Quand ton ouverture d’indentation est ouverte deux pages plus haut,
savoir si pour passer où se situe la section suivante que tu cherches
est parfois une galère sans nom. »
Alors qu’en XML ça n’arrive jamais je suppose. Le fait d’avoir une arborescence qui prend 2 pages est intimement lié à JSON n’est-ce pas. Tout bon editeur IDE permet de sauter rappidement d’une balise/acolade ouvrante à une fermante et vis vers ça et il propose bien souvent en sus la possibilité de réduire/développer une arborescence donc ton problème est plus de la mauvaise volonté (foi ?) qu’autre chose.

Le fait d’avoir des acolade pour ouvrir et fermer des blocks est tellement illisible qu’il est repris dans les principaux langages de programmation (y compris les plus vieux), qui sont, nous le savons tous fait de sorte à ce qu’il deviennent illisibles.

« Sauf qu’oublier la balise fermante il faut le vouloir […] Les balises fermantes ont ça de bien que justement on les ferme tout le temps. »
Alors qu’une accolade fermante on fait expré de ne pas la mettre… Soyons sérieux.

« C’est encouragé par le fait qu’il faut une virgule entre deux éléments
mais pas sur le dernier, donc quand tu retires le dernier, ou que tu le
déplaces, il est très facile de laisser ou oublier de rajouter la
virgule. »
Je suppose que tu ajoutes régulièrement des virgules après le dernier argument de déclaration de tes fonctions….

« Et ? « 
Et, ben ce n’est pas lié au format à proprement dit.

« Et non, ça vient aussi du format puisqu’il n’y a pas de DTD ou équivalent en JSON donc l’éditeur aurait du mal à l’inventer »
Et il n’a pas à le faire (comme @naholyr l’a dit). Et encore une fois, si tu écris du JSON/XML à la main, you do it wrong.

« voilà mon calcul. »
C’est le fait de partir du fait qu’un JSON « lourd » est forcement illisible et d’en faire une vérité génrale comme si c’était admis qui me choc, pour ce qui est des stats, on a beau retourner le problème dans tous les sens, JSON est plus performant à lire/écrire/transférer que du XML, et ce sont des amateurs qui n’ont pas du tout des problèmes de performances qui le disent comme Google (voir communiqué de presse concernant protocole buffer) ou Twitter (qui a abandonné XML pour ses API au profit du JSON)

« C’est encore plus vrai quand le JSON est transféré après le chargement initial de la page. »
Dans le cas contraire, il n’a pas besoin d’être parsé puisque c’est un subset de Javascript.

« Dans d’autres langages il y a une différence entre ce qui est natif et ce qui ne l’est pas. Mais je ne t’apprends rien ici. « 
Et en comparrent pas natif vs pas natif et natif vs natif, JSON s’en sort toujours haut la main, et même en JSON pas natif vs XML natif, je ne pense pas trop me mouiller en disant que JSON n’a pas à palir ne srait-ce que du fait de la RAM consommée car plus léger (et oui).

« quand même de charger 5K de js dans le navigateur pour avoir une
interprétation non native (tu vois, ça a une influence de ne pas être en
C :) »
Encore une fois, tu prends un exemple bien précis, dans un langage bien précis et sur des outils obsolettes.
Je peux sortir un equivalent pour XML mais j’ai l’honetteté intelectuelle de ne pas le faire.

« Que XML. Euh, ce n’est pas assez clair dans le billet que je compare les deux ? »
Dans le même genre : une banane est plus performante qu’une tomate. Il me faut un plus de détail, merci.

« Navigateurs obsolètes c’est vite dit. Si tu ne veux pas jeter IE7 ou
iPhone 3.2 il faut le prendre en compte. »
Oui, le fait est qu’avoir deux versions de retard rend un navigateur obsolette.

« C’est quoi la bonne méthode
pour toi là dessus ? »
N’utiliser des rustines que si necessaire. Tes 2,5Ko (http://ge.tt/4NILmby?c) ne concernent que des cas particuliers, il ne faudra les utiliser que dans ces cas particulier. Je ne pense pas que l’idée de faire bien les choses en ne chargeant que ce qui est nécessaire est lié à JSON.

Ensuite, je le répète, le problème est identique du côté DOM puisque, je le répète aussi, chaque navigateur et chaque version de ce dernier à son lot de bugs / différence d’implémentation que des librairies tel que Mootools, jQuery, YUI et conssort s’appliquent à effacer (querySelector, getElementByName/Id buggé etc.)

« Qualifies « bien » ? »
Ce qui est avantageux ou utile à une fin donnée. Ce qui possède une valeur morale, ce qui est juste, honnête, louable.
Mon exemple ne t’a pas suffit ?

« Dans ton exemple tu as sur-architecturé au départ. »
J’ai juste transcrit la façon de faire d’XML.

« Si on te demande une liste de prix tu aurais vraiment dans ton json mis
liste: [ {prix: 3}, {prix: 5} ] ? je parie ma chemise que non. »

C’est pourtant ce que tu fais en XML.

Tu veux dire que c’est pas optimisé de répéter 20 fois prix ? C’est marrant, c’est justement ce que je reproche à XML. En JSON, tu choisis une architecture pertinante (ou pas, c’est ton problème) selon le besoin, en XML on t’en impose une lourde).

« Le fait que dans 5 ans on aura du support n’est pas pour moi un argument pour choisir maintenant un format. »
On l’a déjà le support, Dieu merci, on a pas attendu de convaincre les gens avant de profiter des avantages de JSON.

« Je râle toujours autant contre la sur-utilisation de XML à des endroits où c’est stupide notes bien ;) »
Et moi sur les vérités générales établies sur des exemples biaisés.