Use both. Just take a few measures to prevent identity theft.
Okay, but let's talk how to do that.
JWT is not a replacement for cookies. It couldn't be, as they have different purposes.
In a web app (e.g., not a web api), cookies are still the safest and best overall to transport credentials over HTTPS. In fact, there is at least another established way to store credentials. It's the HTTP Authorization header. The trouble with authorization headers in a web app is that they will be available to client side scripting, and when long term session is required, we'll need to store the credentials somewhere. There's no safe way to do that in browsers. So authorization headers are best used in web apis consumed in server side.
Traditionally, a session cookie only stores a pointer to data stored somewhere else. A server would have to decode the cookie and then fetch the data it points to. For large systems, a cache or session database is used to avoid tying the user to a single server. Now enters JWT.
JWT is a message format that can contain all information the server needs to process requests, like identify the user. It saves the server from performing a request to fetch further data. The complete payload is signed and sent alongside the message to confirm it is valid. It's not a hash nor it is secret, so no sensitive information should go in there. Now, we still need a medium to transport the JWT between server & browser. A Secure, HttpOnly cookie fits like a glove.
Larger systems benefit from JWT because any server could serve a request, unlike a session cookie usually (unless as stated above) tied to a single server.
There are other pros & cons for each as stated by Anders in his answer, I'm not going to repeat it all over.