Nonces are not magic bullet that by simply applying it everywhere your site get more secure. Talking broadly, nonce should be applied only to logged in users, and serve little purpose when applied to non logged in. Even for logged in users, there might be situations in which nonces are just not needed (like when reading publicly available information).
…. but when coding, it is truly easier to apply nonces everywhere instead of having repetitive checks whether a user is logged in. Still, if it is important for you that a page can stay open for more than a day and still retain all its functionality, that is the way to go – remove nonces where they are not needed.
The nonce issue you describe is the result of WordPress not implementing nonce as the definition implies. Nonces are supposed to be unique per page load, while WordPress reuses them for 24 hours. This has a huge performance and architectural advantage as it removes the requirement to store them somewhere, but leads to problems like the one you describe which are hard to eliminate without resorting to a “forced” reload of the page every 24 hours. therefor the other solution to your problem is to override the nonce api with your own logic to generate a one time nonce, or use different time interval for non logged in users.
Why not to detect the expiry somehow in JS? because nonce are generate by using secret “SALT” keys, and the only way to reconstruct the calculation is to expose them in your JS, at which point they will not be secret any longer.