This doesn't seem too much better than just writing out the hook manually

I think it's a lot better than writing out the hook manually, as that doesn't get you systemparams, complicates resource access due to aliasing rules (like having Assets and AssetServer at the same time), and adds extra lines to do anything appreciable. I think it's more in competition with the setup observer pattern which is what everyone seems to be leaning towards.

Compare:

#[derive(Component)]
#[component(on_add)]
pub struct Test;
impl Test {
    fn on_add(mut world: DeferredWorld, ctx: HookContext) {
        // these must be ordered like this to avoid mutably borrowing world twice!
        let asset_server = world.resource::<AssetServer>();
        let mesh = asset_server.load("mesh.glb"); 
        let mut materials = world.resource_mut::<Assets<StandardMaterial>>();
        let material = materials.add(Color::WHITE);
        world
            .commands()
            .entity(ctx.entity)
            .insert((Mesh3d(mesh), MeshMaterial3d(material)))
            .observe(my_observer);
    }
}

#[derive(Component)]
#[setup(setup_test)]
pub struct Test;
fn setup_test(
    entity: In<Entity>,
    mut commands: Commands,
    asset_server: Res<AssetServer>,
    mut materials: ResMut<Assets<StandardMaterial>>,
) {
    // freedom!
    commands
        .entity(*entity)
        .insert((
            Mesh3d(asset_server.load("mesh.glb")),
            MeshMaterial3d(materials.add(Color::WHITE)),
        ))
        .observe(my_observer);
}

I also don't like that setup implicitly adds the on_add implementation, without clearly implying it in the name. I can picture someone trying to add both and getting errors.

As implemented in this PR you can have both and they get combined without errors (see the macro expansion)

Another potential footgun here is that the setup method runs a one-shot system with a command, so it's deferred

Yup that seems like a potential issue, fair enough.

Having something like setup also makes me wonder, where's the equivalent for on_remove?

Destructor patterns seem to be way less common but I could add sugar for that too for consistency!