Hey. My Quest implementation (the one I created after this wiki article) follows along similiar to what you have state you would do. I had a UObject base class that was call UMission that was merely a collection of UObjectives (where they were also UObjects, marked with a Within UCLASS specifier to exist within only a UMission, while have type safe access to it’s outer’s interface). From there each UMission had UReward objects to support adding a reward system. Each of my UMission objects implemented BeginPlay, Activate, EndPlay, Deactivate, GetWorld, GetLifetimeReplicatedProps, ReplicateSubobject (to replicate UObjective and UReward Collections and children UMission Objects). From there, I added an entirely evented system as well. I also implemented several UObjectives for common event handling. Such things were Time Trials using the TimerManager and custom Notifications received from various Actors in the Game.
However, from there, to support networking, you would also need to get some kind of interface for the UMission to interact with the world. These interfaces could be something as making it a Subobject of an AActorComponent to make easily plug and play into your game. Another way would be to make it a Subobject of an AActor class (which supports subobject replication without hassle and RPC) such as AGameState (Server Only) or APlayerState (Replicated to all Clients).
Couple things to mention about your argument against using AActor. It is not just for BeginPlay and Tick. It is because of the fact that they support the replication of subobjects out of the box, they support RPC out of the box, AInfo does not have a Transform within the world, it is the whole point of the class, to have an Actor that does not have a position within the world - just information. AActor does not have to have any Components and perhaps the use of components would be an easy way to extend the AQuest object.
However, the most painful part of the whole Quest thing within UE4 is that most system that are for sale fail on multiple accounts due to being data driven. This leads to generic, flat, and uninspired quests. The best quest system would be able to be dynamically created, that is why UObjects are best, AActors should be used for ease of use / prototyping, and custom implementations do not require a lot of overhead. Finally, the hardest part would be implementing a good design UI for your quests.
In a closing note, using AActors would be easier for a beginner, as UObjects require a lot of work and integration if it is to be a multiplayer game. On top of that understanding how instancing and DataAssets work would be more overhead as well. But, there are always a hundred ways to do the same thing when it comes to programming.
Final Remarks: " in the end the idea is always the same: A quest has conditions and is alive until we succeeded or failed them." - I find this the crux that quest systems lack robustness. Would it not be better to implement quests more like a dumb weight based AI system that selects the result of a quest completion test? I find that questing does not have to be/is not binary in nature.