Basically, if I took the standard approach of creating interfaces for all the services + default implementations, that was going to:
1. Increase the size of the .dll which I am desperately trying to keep as small as possible.
2. Require more intricate configuration on the part of the developer, especially registering lots of things with an IoC.
3. If I tried to come up with a generic registration system like Caliburn, that was going to force me to introduce a significan IoC abstraction, along with all its complexities, which would again increate the .dll size significantly.
I felt that making public static Func/Action fields was a reasonable compromise which would enable extensibility in the most common places without adding lots of interfaces or an IoC abstraction. Also, having looked at the types of things that Caliburn users
have customized in the past, I felt it was overkill to try to push all of Caliburn.Micro's services into a container. That's the brief explanation at least.