This is what is weird, for live iptv stability is important, so if they enabling g.inp for that configuration then it suggests g.inp in a general sense is considered more stable than the legacy configuration.
This leads me to speculate one of 2 scenarios.
1 - g.inp works well on ECI providing its not enabled on many ports, perhaps a cpu utilisation issue, I dont think this is the case, g.inp shouldnt need much processing power compared to say vectoring.
2 - there is compatibility issues as has been reported but BT retail decided they would deal with those issues and reported to openreach as such, which led to the situation we have now, but not for their entire customer base, just for their iptv customers. This seems the most plausible.
3rd possible situation.
3 - openreach have it enabled for all isp's that use iptv services, the accounts flagged could be the ones set to use the iptv qos flag on the cabinet to exchange backhaul. Is there other isp's iptv customers that have g.inp enabled which would suggest this is the case?