While the DVWA difficulty settings are helpful in test environments to try things out, I wouldn’t necessarily think of apps you’re testing in the real world as mapping to the “Hard” or “Impossible” levels. Every app is different and some apps may have both vulnerabilities that are extremely easy to exploit, while at the same time having very difficult ones to exploit.
I know some people use the term “exotic” payloads, but I don’t really know what that means. To me, a payload is a payload. I don’t really know what would make one payload more exotic than another apart from one person’s opinion. What I’m trying to say is that having a list of various payloads you can pick from is helpful, and that list should be wide and deep because a payload that might work on one application could be completely useless on another (no matter how ‘exotic’ it is). ‘Basic’ payloads can also still be useful in testing out the application initially, to see what gets blocked, filtered, sanitized, etc…and then from there, you can narrow down payloads that are more likely to make it through.
So just because <script>alert(1)</script> is very unlikely to make it through nowadays (though I bet you could still find low-value targets that are still susceptible to that payload, unfortunately), it doesn’t always mean that the payload is completely useless. How is the application responding to the payload? Is it stripping out the words script? Is it giving you an error response? Is it stripping out the < > / but keeping script & alert(1)? It gives you clues as to what’s going on behind the scenes. Use that information to iterate and go from there.