MAC schemes like JWT provide message integrity and a form of authentication that can't always be provided by TLS/HTTPS.
The simplest way of describing it is that with HTTPS, when sending data to/from a server and a client (the client may even be another web server) you can be assured no one but the server or client can see or tamper with the data in transit.
But the client is still able to trick the server, or vice versa, at the application level. To prevent that you need a message signing scheme (aka a MAC), and this is an example of one.
For the case of password reset links from an email, generally speaking there's no point in using something like this; a one-time random token that you track and expire on the backend makes more sense. You'd only want to use a MAC if you need to freeze some kind of state in the URL and retain it, like perhaps a user's IP address. Then you can verify that the user's real IP address does indeed match the IP address in the URL; they can't tamper with the URL to change the IP address if a MAC is used.
I don't know why anyone would want such a feature for a password reset function, and you could also replicate that same behavior just by storing the IP on the backend as well (though while also perhaps making your application somewhat more complex in the process), but that would be one example of doing something like that in a secure manner while still letting the client keep track of the state instead of the server.
One common use of tokens like this is to defer state retention to all your clients so your server can do less work per request and store less data. Simply verifying that the MAC for a message is valid in every request is a lot faster than making a database/data store query to return session info for every request.