I disagree with the component handling both the movement of the door and the delay, as well as the trigger volume. In my experience, the additional features of the component would end up being set to 0/Null most of the time, as more in-depth scripting would inevitably be necessary as the project expands. Therefore, I prefer to have the triggering to be handled as a UFUNCTION exposed to my custom owner class(and then to level blueprint - no point being stuck with the default trigger volume) and the delay to be handled by the owner class as well.
Having the mechanics be all hidden in a component on a non-custom actor class decreases clarity as well, the necessity of adding it by hand to every door would probably result into a lot of bugs ranging from unopenable doors to entire buildings suddenly pivoting because someones hand slipped.
Of course, implementing it the way the course suggests had some additional didactic value in terms of getting the hang of C++, that’s probably why it was done like this.