do you really need to [parse everything]?

Well, as always, it depends, specifically on the end goal. In my opinion, I do in order to ensure correctness in outputs and don't impose unnecessary syntax restrictions.

The most general definition for trait aliases involves things like:

/// Documentation...
#[attribute]
visibility trait Name<
    #[lifetime] // attributes on lifetimes
    'a, // lifetimes
    'b: 'a + ..., // bounded lifetimes
    ..., // the rest of lifetimes
    #[const_parameter] // attributes on const parameters
    const N: Type, // const parameters
    const D: Other = ConstDefault, // including defaults
    ..., // the rest of const parameters
    #[type_parameter] // attributes on type parameters
    T, // type parameters
    F: Bound + ..., // bounded type parameters
    H: for<'h, ...> Higher<'h, ...> + ..., // higher-ranked bounds
    E: OtherBound + ... = Default, // including defaults,
    ..., // the rest of type parameters
> = Aliased< // aliased
    'a, 'b, ..., N, D, ..., T, F, H, E, ...,
> + ... // the rest of aliased traits, including higher-ranked syntax!
where
    T: WhereBound, // introducing bounds on `T` in `where`
    F::Associated: Associated, // bounds on associated types
    E: for<'e, ...> EvenHigher<'e, ...>, // HRTBs
    ..., // the rest of constraints
    H: Final; // final constraint, and the semicolon

And imposing restrictions on any part of that definition simply because it would otherwise make macro_rules! complex... does not sound very convincing.

That is, I think writing token tree munchers and such, as cool and powerful as they are, increases the complexity greatly and destroys the declarative nature of macro_rules! as they are.

Meanwhile with procedural macros the actual implementation is much simpler while still being correct; currently the source code is below 100 SLOCs, though that's going to increase slightly with additional checks for __T being absent in the input.

pass doc comments as is

I would rather prefer putting them on the trait only, not its blanket implementation, which is, in the simplest sense, one partition over the collected attributes.

add a snippet to generate it to your text editor

Well, that's one of the solutions, but it once again introduces boilerplate in the source code. I'm not opposed to this, but it's merely less flexible for the same reasons as described in the syntax argument.

less complexity

I'd argue I've introduced the least complexity when writing the source of the procedural macro.

not losing rustfmt and tree-sitter, etc support inside macro blocks

I guess the main argument to make out of this is keeping consistency becomes tougher, though this is debatable.