As with anything where you are using security practices, the exposure and threat assessment are something which you will have to evaluate for your unique environment and use case. The existing answers provide plenty of touch points for that evaluation, as well as pointers for things to avoid - such as GET triggered actions. Instead, I'm going to focus more on the "user" part of the UX. I will touch on many of the comments scattered about on the page as well.
Exactly what you are "verifying" with the email-triggered action is a factor to consider, as well. If all you are doing is confirming that it is a valid email address, then almost any action will be sufficient. Verifying the email, the intention to create the account, and that the user receiving the email is the user who initiated the account creation requires a bit more effort.
One "effort" you should not have to take, however, is the sending of reminder emails. Assuming the user intentionally created the account, used a valid email address, and wishes to use the account for whatever purpose you are offering accounts, they will be looking for the email, and will undertake the activation process as soon as they are able to. The link, code, or whatever, might expire before they use it if they get sidetracked on other matters while waiting for the email. Allowing them to resend the verification email in such cases is fine. A reminder email, however, is much more likely to be a spam trigger than a benefit to the user.
As a user I appreciate having options available to activate/verify my account. The most common option set I've encountered is where the email provides a link which I can either click or cut & paste, and a confirmation code which I can enter into a form field on a page within my account settings area on the website. Seldom is the confirmation code anything but an integer, 5 to 9 digits long.
The verification emails which give me, as a user, the most confidence are those which have a crypto-looking hash in the URL (/verify?l=lgGS2SBjMTU4NjkwNjYxMjI5MDBhZDk2YjEyMzMzYjNhZmQxOb), which takes me to a page unique to me where I then have to enter the password I used to create the account. The use of the hash confirms that the link was received in an email, not guessed or brute-forced, thus verifying that the email is valid. The serving of that unique page, prior to any other actions, allows the server to mark the email it was sent to as "valid" without confirming the account creation. The entering of the password confirms that there is an actor on the other end, as opposed to some anti-virus, malware detection, or pre-fetch operation. The validity of the password confirms, to a reasonable degree of certainty, that the receiver of the email and the creator of the account are the same person.
The proposed time-limit of 30 minutes does seem a bit severe, while a 24-hour period might be too large if your threat assessment suggests that your exposure in 24-hours is unacceptable. I believe that 2 hours should be sufficient to almost any user's environment. Especially so if the ability to resend verification is available. Even using a mobile device with a 14 kb/s connection to a remote POP account should be able to complete the exchange inside 120 minutes.
The use of JS to somehow verify human actions can be problematic. JS can be turned off, and is much more often than many web developers would like to know. Secondly, ad blockers can block JS on a per-site, or per-source, basis even when JS is enabled in the browser. I block many JS sources, including Google's analytics scripts, on a global basis, and whitelist some for sites, such as Stack Exchange, where I'm willing to support them with the use of my data.
Including a link in the email, or on the confirmation page, to "cancel" the account is a waste. In the email it is actually counter productive in that is suggests that clicking on a link about an account you don't want is a good idea. Instead, the email should include verbiage to indicated that doing nothing will cause the account to not be confirmed, and maybe deleted. A link to cancel on the confirmation page is even worse, as it is rewarding bad behavior. I frequently get emails, as part of an old Google snafu, directed to another Gmail account, and I presume the opposite is true for the other account as well. [In the old days Google didn't merge dotted and undotted user names, so my dotted user name and someone else's undotted version are different accounts, yet Google will slip up once in a while and I get their email anyway :( ]
How tightly you couple the "verified" email address with the activation link is a function of your use case and threat assessment. I am mildly annoyed when I have to re-validate my account after changing the associated email address. How accepting I am of the process is proportional to my "value" of the account. For my bank account, PayPal, etc., I'm 100% accepting. On PcPartsPicker, however, I'd be around 15% accepting of such a process.
As to the IP and/or user agent, ignore them. As a case in point, I often will view sites, and choose to create an account, using my mobile device. I will not, however open emails on it. If I create an account, and learn that I need to verify or confirm it somehow, and email is the offered method, I'll wait until I get home to open the email on my desktop, where I can inspect it. The IP and user agent will thus be very different. My password, however, will remain the same, and that ought to be sufficient to verify me as the original account creator.
Just remember that emails are about as secure as the Jumbo-tron in Times Square, and proceed accordingly.
