I don't address the correctness of the regex in this answer. You might want to take a look at this article on URL validation and customize it for your matching task.
Problem
Your regex includes classical example of catastrophic backtracking in the form of (A*)*
.
For example, in this portion:
(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+
If you throw away the second branch, you will immediately see the problem:
(?:[^\s()<>]+)+
The second branch also contains an instance of the problematic pattern:
([^\s()<>]+|(\([^\s()<>]+\)))*
degenerates to:
([^\s()<>]+)*
To demonstrate the problem you can test your regex on this non-matching string:
sdfsdf http://www/sdfsdfsdf(sdsdfsdfsdfsdfsdfsdf sfsdf(Sdfsdf)(sdfsdF)(sdfdsF)(<))sdsdfsf
Demo on regex101
Solution
Using the snippet above from your regex to demo:
(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+
^ ^
In languages which supports possessive quantifier, since the 2 branches of your regex are mutual exclusive, it is an option to make those quantifiers possessive.
However, since Python doesn't support possessive quantifier, you can remove the quantifiers at the positions marked without affecting the result, since it has been taken care of by the quantifier in the immediate outer layer.
The final result (which takes care of the same problem in the last group):
(?i)\b((?:https?://|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}/)(?:[^\s()<>]|\(([^\s()<>]|(\([^\s()<>]+\)))*\))+(?:\(([^\s()<>]|(\([^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’]))
Demo on regex101