This line of code is found inside the ISR void handleAnemometerEvent() but you need to be aware that millis() will not be serviced inside an ISR, so it can't be used to measure the time spent inside.
On the other hand, since your vtimeAnemometerEvent is only local, the value will never be seen outside of the ISR (but your lastAnemometerEvent is used for that, I see).
But, as @Moors7 said, having a shorter code to look at would make it easier to focus on the code that actually may cause the issue, instead of having to plough through code you know works but we don't know which is which 
Also having the pin designations stated in one place would make it easier to judge whether or not you may run into shared interrupt issues or other HW limitations.
Yes, uint32_t is exactly the same as unsigned int on these controllers.
But
Time.now() actually returns an int (UNIX epoch time UTC - Time.local() would return UNIX epoch time corrected for time zone, if set).
Where do you do the wind reading over 30 seconds?
I can't see that happen. AFAICT you are rushing from initializeAnemometer() through to reading as fast as Particle.connect() takes to do its job.
I also don't see the use of delay(5000) before Particle.publish() and delay(10) is a bit short if that's meant to allow for the publish to actually go through (for system versions that don't take care of succesful delivery before goint to sleep).
I also took the liberty to reformat your code and reduce some of the superfluous blank lines and excessive indentations, that just strech out the code, to get more code lines into view at once.