There are a few reasons why this isn’t default (and why it’s difficult to make it the default in vCurrent)
There is no separate AST representation for them (not in vCurrent at least - there is in vNext), so they can’t be connected in the “regular” way.
Change tracking is fundamentally different from other kinds of observation (callback returns splices instead of the new value, and also does not return the old value).
Change tracking has a huge overhead compared to other forms of observation because of the Levenshtein distance calculation.
So like @bigopon mentioned they are not observed by default for performance reasons. @davismj making it a default would be a huge performance regression in many apps.
Array bindings in a template are usually repeater or select related and those already take care of array observation internally.
When you’re binding the array to some other custom element, you typically instantiate an array observer via the binding engine in the view model.
For a value converter and binding behavior arguments it kind of makes sense to have array observation on by default, just like select and repeat does, but it’s not quite the same thing. For select and repeat the array observation is key to their function and they fully utilize the splices (at least the repeater does).
For converters and behaviors it would be nothing more than an update trigger - the splices would never be used.
In that regard, a clean(er) solution than turning this on by default might be to have an opt-out for the Levenshtein distance / splices calculation. That’d be tricky though. I’m certainly going to give this a try in vNext (where we don’t have this distance calc) and perhaps the rest of the integration can somehow be backported if I figure out a clean opt-out. Not sure yet.