After reading through it a couple of times, I think I got the idea. "@default removes all non-default properties and attributes."
It's a cool idea, but I'm not sure it'll be very easy to read in practice? Another concern of mine is also that it might be a mess if the default attributes change. Of course, that's fairly unlikely, but if everyone was used to explicitly annotating functions then it'd be less of a big deal.
I'm also unsure if it's the most elegant solution. In this case it's nice:

pure:
void myPureFn(){}
void myImpureFn() @default{}

But in this case, not so much:

@nogc nothrow pure @safe:
void myPureFn(){}
void myImpureFn() @default @nogc nothrow @safe{}

That said, it does eliminate the headache of having to remember what exact properties attributes are collectively applicable for the current function:

@nogc @trusted:
void myFn1(){}
nothrow pure:
void myFn2(){}
void myFn3() @nothrow(default) @safe(default){} //what is happening!?!?

Overall, it's probably one of the better approaches to this issue I've seen proposed.

Thinking it through, this can be an extension of @safe(boolExpr): @safe means @safe(true) and @safe(auto) means “infer if @safe or not”. In contrast C++’s noexcept(expr) expression (that returns true when expr is noexcept), in D, isSafe can be a simple overload set and be used like @safe(isSafe({ stmts; })):

bool isSafe(void delegate()) @safe { return false; }
bool isSafe(void delegate() @safe) @safe { return true; }

@default (or just default) could (should?, by its name) be an abbreviation for all the named and unnamed function attributes that are the language default for the construct, i.e. @default represents @safe(default) (= @system), const(default) (= mutable), pure(default) (= impure), public(default) (= private for imports, public for everything else) etc., and @auto could be an abbreviation for a similar sequence with auto as its argument, i.e. infer all except visibility attributes, which cannot possibly be inferred. What it includes is up for debate because e.g. const could in principle be inferred.

Another problem this DIP might have is that attribute: is increasingly frowned upon for attributes that are not either visibility attributes or – maybe – really and absolutely by the nature of the aggregate or module of that property.
Visibility attributes have sane defaults in D and are rarely needed, also they’re never inferred and can be undone easily.
People (myself included) will say: If you happen to find yourself in needing @default, just don’t use attribute: or attribute { … }. It makes it even harder to figure out what attributes apply to a declaration.

If you happen to find yourself in needing @default, just don’t use attribute: or attribute { … }. It makes it even harder to figure out what attributes apply to a declaration.

If you can record a video of yourself writing 100 empty functions in a attribute{ /*...*/ } block, and then the same but manually writing the annotations for each function by hand (which should be @nogc nothrow @safe pure pragma(inline,true) deprecated("Scheduled for removal in version 3.0, please use nameHere instead."), of course) but in the same amount of time as the first video with you typing at the same speed... then maybe I'll be convinced. ;)

Jokes aside, no I'm not wasting my time with that. Even Phobos uses attribute: all over the place. @nogc nothrow: is really useful when you want all your code to be BetterC compatible, but @nogc on CTFE'd lambdas disallows string concatenation! A travesty! Hence, @gc or @default or whatever would be very useful for the ONE piece of CTFE-only code I write in the middle of code that has to have a bunch of specific attributes.

Another problem this DIP might have is that attribute: is increasingly frowned upon for attributes that are not either visibility attributes or – maybe – really and absolutely by the nature of the aggregate or module of that property.

How do you know it's "increasingly frowned upon"?

If you happen to find yourself in needing @default, just don’t use attribute: or attribute { … }.

My code has 171 occurences of the line @nogc nothrow pure @safe: and 32 of nothrow pure @safe:. I don't want to repeat those attributes even more than that, it clutters all the function signatures.