From the point of view of a developer/designer of interfaces: this doesn't sound very convincing.
Let's say that cross-game chat requires a daemon ( a background system process, that is ). And let's assume that it wreaks havoc with some weirdly coded existing games.
As a coder, I'd say that you would add a couple of system calls to the OS so that a game can start/stop the cross-game chat service at will. And also add a toggle into the in-game XMB UI, with a lower priority than the code calls.
Also, the OS knows which game you're running (I suppose each one has a unique string ID) and can very well take care of saving your settings for each game. The default would be that the service is Off.
This way:
1) all "new" games can call the "turn cross-chat on" when they want, or disable it when they want. To the user, it's a transparent thing: they load their game, it has the feature.
2) all "old" games are run initially with the service disabled as they don't have the code calls, unless they are patched by their authors. The user would have to turn the service on from the in-game XMB the very first time, then the setting would be saved by the OS and be On automatically during subsequent runs. If it causes troubles, then the user will have to turn it off, it will stay off in subsequent runs and that particular game won't have the feature but it won't be broken, either.
Such calls are analogous to what I assume are now in the OS for the custom soundtrack, for both 360 and PS3. On the PS3 because by default it's off so there must be software switches, and on the 360 because I know that developers can add calls to their code that fade out the custom soundtrack and force the games one if they want (say, in a cut-scene or when the music cue is really needed)
And obviously the same "user turns it on once in the XMB" could be used for custom soundtracks in old games, too... all in all it's such an obvious solution that I don't know what to make of the original quoted post.
