From an IDE perspective (especially with completions in mind), allowing to jump out with an error by default like this will make the macro experience for tools even worse than it already is. An IDE ideally wants proc-macros to expand to something reasonable at all times so that it can decently calculate completions for the current cursor location. So from an IDEs perspective, whatever parsing power we want to give to proc-macros by default (that is dependency free) should allow for some kind of recoverable parsing. If a proc-macro completely discards its output for error reporting this no longer works. You could argue that for attributes at least the IDE could just re-use the input as the output for its analysis, but that alone still loses a lot of meaning for the input.
As an example think of a token being re-used in some way in the expansion. Now this token will lose and gain analysis information on its usage whenever the input changes from valid to invalid and vice versa while typing which could result in flickering highlighting (with semantic highlighting), hover no longer showing expected things until the input is valid again etc. (This is strictly speaking about syntactic requirements the macro imposes, not rust syntax as r-a fixes up invalid rust syntax in attributes as is required).
Now for function like proc-macros re-using the input obviously does not work as the majority of them will not have proper rust syntax. Here the IDE won't be able to do anything without the proc-macro helping out by trying its best to keep expanding on invalid input.
As for derives, it is less severe as the only input where this somewhat makes sense for them is in inputs to derive helpers, but here as well the macro can help out by not bailing out immediately as completions could be offered in these positions as well!
So with that said, I'd rather we explore a default parser mechanism that allows for recovering on unexpected inputs and nudge the proc-macro authors to write "infallible" macros (and make this easier than it is today!).
As an aside for error reporting which would be relevant given my argument, there is a proposal for a diagnostics API which would allow to easily report errors without returning some kind of error type, panicking or having to emit a compile_error! invocation: https://github.com/rust-lang/rust/pull/83363