After discussion today about how slow are events I've tried to write a small test to see how slow our events are. It was almost obvious for me that because of compile-time code weaving there should be no big overheads in use of aspects to manage events (of course when they are used properly, it is always easy to misuse things 
). Below are results, it looks like it was pretty slow, but we did it, by using Reflection. Taking into account that we did not do optimization at all I did only minimal optimization, actually removed our custom NotifyPropertyChangeArgs implementation and used standard System.ComponentModel.NotifyPropertyChangeEventArgs. As result OldValue and NewValue disappeared. If we will need them - we will have to extend an aspect attribute to use PropertyChanging events. Also we probably will need something similarto implement IEditableObject (transactional object editing) or for implementation of Memento Design Pattern (to implement Undo / Redo). The main advantage is - reuse. Less code is always good plus looking on videos / conferences it seems to be a current direction where programming languages moving to (DSL, AOP).
// Before optimization
// -------------------
NotifyPropertyChangedAttributeTest.SlowDownBecauseOfPropertyChangeEventsShouldBeLessThan250Percent : Failed
1375 [7] INFO 100 000 changes without NotifyPropertyChanged: 125 milliseconds
1421 [7] INFO 100 000 changes with NotifyPropertyChanged: 750 milliseconds
1421 [7] INFO 
>>> 500% slower <<<
NUnit.Framework.AssertionException: Expected: less than or equal to 40.0d
But was: 500.0d
// After Optimization (remove use of reflection in aspect and remove OldValue / NewValue in aspect - use standard .NET 3.5 implementation)
// ------------------
828 [7] INFO 100 000 changes without NotifyPropertyChanged: 140.625 milliseconds
875 [7] INFO 100 000 changes with NotifyPropertyChanged: 187.5 milliseconds
875 [7] INFO >>> 33% slower <<< ... 15x speedup 
Actually it varies ~10-50%. Have no idea why it is slower / faster, probably some .NET or ReSharper pre-compiled bytecode tricks.
33% is a very good price for the functionality we get back.
I guess we will have to write similar performance tests for CollectionChange event.
By the way, the main current bottleneck in the Network classes is an EventedListView, we will need to get rid of it ASAP by replacing it with IEnumerable<...>, only one issue remains is that feature providers will need to be informed somehow that features in collection were changed.