To remain compatible with WPF this should probably be done additionally instead of "instead" of the base class.
So the abstract class should probably implement the interface instead of the interface replacing the abstract class.

The reasons for this feature are simple
a) this is already being discussed for WPF .NET Core
https://github.com/dotnet/wpf/issues/170
b) this is how it was in Silverlight where it proved to be:
c) more flexible. You can made a DependencyObject implement the interface which allows you to have a markupextension with binding support
Or you can have any kind of useful class that you want to be able to easily use in a property attribute instead of a property tag, which keeps the XAML
neater. but that class might have a different base class.