Although I support general direction, the devil is in the details. I can't help but worry that OBI might expose the problems we never knew we already had.
For example in current code witness can only change his vote once per schedule (he can produce block B that has no his previously produced block A in the chain, because he switched forks in the meantime), it can happen only in very specific situation and it still depends on other witnesses if they will accept that change of heart (they can still be on a fork that includes A but does not have B). With OBI the same witness can potentially change his vote couple of times per block, so if there is any problem that would be exposed during changed vote, OBI will make it that more likely to actually happen.
Then there is also a problem of witness signature. Witness can change signature. With current code such change will matter during next scheduled block for that witness. What about OBI? Note that changed signature can still be a pending change (but already in the state)... hmm... I actually wonder if it isn't a problem today (witness changing signature and producing block signed with new one being accepted even though the transaction that did the change was not yet included in any block, possibly never becoming part of one due to expiration for example). I did not check if we could potentially have such problem, I'm just thinking aloud, maybe we actually have something that prevents such situations.
Double producing. Whether it is intentional or a problem of misconfigured backup node, using the same or different witness signatures, now it can only happen once per schedule. With OBI the same node can legitimately vote for some block but revoke that vote immediately after receiving new block on different fork. Depending on network propagation some nodes might think the vote is still valid and act on it - they won't be able to switch forks even though they might find themselves in minority.