Adding something to an interface, whether its a normal or a default method, is a design choice. A choice you'll have trouble taking back later. In that sense, I agree with the view that default methods is a workaround for safely extending legacy APIs and that's how I intend to use them.
For new systems, for fresh design choices, I have moved away from Java to other JVM languages that support more powerful features. Kotlin and Xtend for example support extension methods, which have the same benefits as default methods, but without polluting the interface. They have their own scope and their own visibility level. You can even define them locally inside another method. So, if you're thinking about designing a system around default methods, what you really want is extension methods. C# had them for a long time, but we can now have them on the JVM. Kotlin also has extension properties, which are fantastic for writing cleaner code. My favourite example would be:
public val Int.b: Byte get() = (this and 0xFF).toByte()
which is great for graphics when dealing with unsigned bytes, e.g. you can write
. Will become even more useful when we get value types in the JVM.