Default implementations of individual methods are actually quite a negative thing, as @jrose points out it makes it hard to understand which methods you should implement, etc. And as @ben-cohen points out it's actually much nicer to put code elsewhere to the public interface (.h files anyone? haha).
A complete default implementation could be useful, but better would be multiple complete implementations of a protocol, that you can choose from when implementing it, and one of those designated as default that will be chosen if you don't explicitly choose one. This is called composition, I'm sure most of you know it and use it already, but you have to be disciplined, and write boilerplate forwarding methods a lot.
A much better solution would be to declare a component that implements a protocol completely. Then compose your objects from these components by declaring which implementation to use along with the protocol. If protocols are broken up nicely, you'd be able to write an entirely original class/struct just by deciding what implementations it's made up of and perhaps setting some property-values for those.
This would also solve other problems for which other solutions are being proposed, which overall is cluttering up the language. For example Un-requiring required initializers would just use the default component implementation instead of a clumsy (sorry @Joe_Groff) work-around that breaks fundamental OO principles.