Well, static state/events are generally bad; but whether you wrap them in a service object stored in a static hashtable or make them directly static makes no difference. The "store static instances of service interfaces" approach is only useful when there are multiple implementations for the service.
Really good design would be if every class could get passed a different set of services (a different ServiceLocator instance), but that would be overkill for SharpDevelop - each SharpDevelop process has only one main window, only one solution opened etc.; so static classes make more sense.
But you should try to prevent calling services/anything static in classes that are not necessarily related to the SharpDevelop main window; for example SharpDevelop AddIns might want to be separated in a SharpDevelop-dependent and an independent part; the SharpDevelop-dependent part would be responsible for getting the current project from the service and passing it to the other part.