JWT Security with IP Addresses
My initial thought was that using JWT in a cookie to connect to an API is not the typical use case, why don't you use a standard MVC app then, but that's not your question and actually it's equally secure as long as the token is in a secure, httponly cookie (and of course the implementation is correct). It's just a bit unusual I think.
On to the point, your question is very valid as is your concern about problems.
Is this extra level of security worth it?
It depends. If you are worried about session theft, probably yes. If you keep the token in an httponly cookie (protected against xss), that's more secure than a token anywhere else, but still, your threat model may show different threats and validate your concern. The usual problem is you can't do this, see below.
Will there be any problems with the IP check I am thinking of using?
Most probably, there will be problems. It depends on your users, how and from where they use your application. If they use mobile devices, IP addresses will change a lot and such a solution is out of the question. If they are corporate users in a company internal network, it can be feasible. Anything inbetween is a gray area. A typical home user will have their IP changed once in a while, most people get dynamic IP allocation from their internet providers. An IP lease typically lasts a few weeks (at least where I live), but ISPs can configure it any way they want, it can be a day or even shorter.
So reality is if you have a normal, usual userbase, you will most probably run into problems.
One typical solution you can choose to do is offer this option on the login screen. If a user chooses to use IP address validation, he opts for greater security but accepts the fact that sometimes he may have to log in again. Or he can choose lower security with his session being more stable. Whether it's worth to explain this to your users is I think a business decision.
Update in response to Edit 1 :)
As for why I think using a JWT this way is a little unusual: I think JWTs are mostly used when tokens need to be passed to different URLs (to different services). For this purpose, httpOnly cookies are obviously inadequate because of the same origin rule. If you can afford using httpOnly cookies, you could just store your session info on the server side. Also I'm not sure whether your JWT only has a session id or if your server is stateless and all session data is in the JWT. In the first case, you don't even need the JWT, you could just pass the session id as normal, and standard .Net MVC does that for you. If it's session data too, JWTs are unencrypted by default, so session contents will be visible to endusers, which may or may not be a problem. (And a JWT is protected from tampering by its signature, so it's only about confidentiality, not integrity). Storing session data in the JWT and the JWT in the cookie may also face cookie size issues, depending on your target browsers.
As for lease renews resulting in the same IP: Well, they don't always. It depends on your business case, but some ISPs give you IPs only for a short time. If it's ok for your users to get logged out once in a while, then it may be ok for wired (home) users. And it is definitely a big problem with mobile devices.