Saying
that it is an anti-pattern to make public methods virtual or abstract because of the developer of a derived class that implements Method1 and overrides Method2 has to repeat the argument validation
is mixing up cause and effect. It is quite the other way round:
If one wants to design a method in a way it provides some fixed argument validations in all derivations of the class (or- more general a customizable and a non-cutomizable part), then it makes sense to make the entry point non-virtual, and instead provide a virtual or abstract method for the customizable part which is called internally.
But there are lots of examples where it makes perfectly sense to have a public virtual method, since there is no fixed non-customizable part: look at standard methods like ToString or Equals or GetHashCode- would it improve the design of any code to have these not public and virtual at the same time? I don't think so.