Mainly because poll is defined as @classmethod, so blender can call it by just having the class definition, rather than needing a specific object/instance of that class/type. So the ‘self’ argument you’re getting in the poll method is not the same as the one you get in execute. You can easily check this by putting a print(self) statement in both methods: you’ll get your operator-derived class in poll, and a bpy_struct in execute.
The poll method is not where you want to verify that your input properties (like v1&2) make sense; you should do that in execute. Every time the user changes a value, your operator needs to be executed, so the user can see the results of the change. This new property value may be invalid, though, so you’ll need to check everytime. If the input is invalid, report/log a warning/error and return something other than {‘FINISHED’}.
The poll method is there to check if your addon could possibly be run in the current context. Eg, if you write an addon that generates a lofted mesh between 2 curves, you would want to make sure the user has 2 curves selected. If not, your operator should not be usable/clickable/visible. The add-mesh-loft operator cannot be used when you have selected a lamp and 2 empties. Blender doesn’t even have to make an instance of your operator (let alone check the sanity its properties) to determine this.
HTH,
g