ObservableCollection is an essential API in WPF framework that provides notification as items are added or removed from the collection, this notification is used by collection controls to help refresh the view (not to be confused with WPF CollectionView). The ObservableCollection API is just OK for most most trivial purposes, but the moment you start using in an enterprise system it starts to show its dark side.
The ObservableCollection is a major pain point of WPF and demands a major overhaul for a long time now, some common issues are:
(1) The observable collection cannot be updated from the background thread, if you are adding/removing to the collection from a background eventing system (think Rx or likes) on your view model or controller, then every update requires you to marshal to the UI thread first. Thus the API is very view centric,
(2) You cannot batch add/remove a number of objects to the collection (there is no AddRange API in ObservableCollection). Worst every insertion or deletion requires a layout update, thus if you have a stream of hundred of updates or more (very common in financial firms to have a hundred thousands of updates) then each update requires the view to do a layout update, this kills the performance exponentially.
There are workarounds for both issues (such as using writing wrapper to automatically marshal to UI thread, binding via bindinglist, or delayed notification by overriding observable collection), but then you cannot expect every one to write the repetitive code for every project, this should come out of the box for free with with the WPF Framework.
Read more: My musings on .Net Technology