In theory that's true, but in practice out-of-the-box defaults and culture matter enormously and differ greatly between JSON and XML.
With JSON, you have to go looking for this sort of trouble if you want to find it. An out-of-the-box JSON parser is all but guaranteed not to coerce a schema, fetch remote resources, apply namespaces, and so on -- if you want to do those things, you have to go out of your way to do them, and your decision to do so is likely motivated by considering tradeoffs rather than cargo-culting because the decisions are A) explicit and B) made in a cultural context where schema-free and remote-ref-free JSON is common practice rather than a sneered-upon possibility.
With XML, you don't have to go looking for trouble, the trouble finds you. XML's ecosystem absolutely did push everyone in the direction of using schemas and remote-refs. DTDs were both common and encouraged with a heavy hand. All the Big Protocols used them, and instead of emphasizing the differences between Big Protocol use cases and duct-tape use cases, the culture tended to get preachy about DTDs being "the right way" to do things. If you chose differently, you were amateur scum not worthy of the Enterprise. This encouraged cargo-cult application of DTDs in places where they weren't appropriate (e.g. maximally economic / flexible glue) and for purposes that weren't appropriate (e.g. as a substitute for documentation). It also lent "moral license" to the wrong party in validation-related toe-stepping. Party A turns on validation, Party B sees their integration stop working, Party A argues that if Party B hadn't been writing morally degenerate XML they wouldn't have been caught out and can point at an abundance of preachy XML gospel to back them up. Party A gets away with arguing that an API change isn't an API change, or that a new internet/VPN dependency isn't new. Party B gets trod upon and remembers that XML was complicit in it. Sure, the XML ecosystem could have avoided these problems without a single code-change or standards-change by creating a culture of acceptance around schema-free XML, but they didn't.
When JSON promised both cultural acceptance and appropriate defaults for the common low-rent use case, people flocked to it, and rightly so. The rest is history.
With JSON, you have to go looking for this sort of trouble if you want to find it. An out-of-the-box JSON parser is all but guaranteed not to coerce a schema, fetch remote resources, apply namespaces, and so on -- if you want to do those things, you have to go out of your way to do them, and your decision to do so is likely motivated by considering tradeoffs rather than cargo-culting because the decisions are A) explicit and B) made in a cultural context where schema-free and remote-ref-free JSON is common practice rather than a sneered-upon possibility.
With XML, you don't have to go looking for trouble, the trouble finds you. XML's ecosystem absolutely did push everyone in the direction of using schemas and remote-refs. DTDs were both common and encouraged with a heavy hand. All the Big Protocols used them, and instead of emphasizing the differences between Big Protocol use cases and duct-tape use cases, the culture tended to get preachy about DTDs being "the right way" to do things. If you chose differently, you were amateur scum not worthy of the Enterprise. This encouraged cargo-cult application of DTDs in places where they weren't appropriate (e.g. maximally economic / flexible glue) and for purposes that weren't appropriate (e.g. as a substitute for documentation). It also lent "moral license" to the wrong party in validation-related toe-stepping. Party A turns on validation, Party B sees their integration stop working, Party A argues that if Party B hadn't been writing morally degenerate XML they wouldn't have been caught out and can point at an abundance of preachy XML gospel to back them up. Party A gets away with arguing that an API change isn't an API change, or that a new internet/VPN dependency isn't new. Party B gets trod upon and remembers that XML was complicit in it. Sure, the XML ecosystem could have avoided these problems without a single code-change or standards-change by creating a culture of acceptance around schema-free XML, but they didn't.
When JSON promised both cultural acceptance and appropriate defaults for the common low-rent use case, people flocked to it, and rightly so. The rest is history.