Is it possible to do SQL injection (HIGH Level) on Damn Vulnerable Web App?

The ‘high’ example is not exploitable. It's not a good approach (in modern code you would use parameterisation instead of calling mysql_real_escape_string, and stripslashes is a relic of an era of magical quotes that is thankfully over), but it is designed not to be immediately vulnerable.

(To SQL injection anyway. It is vulnerable to HTML-injection leading to XSS issues, thanks to those horrible echos, but that's another story.)

How come it was so easy to bypass mysql_real_escape string? [in the Medium example]

Because mysql_real_escape_string is designed to escape characters for safety when included in an SQL string literal context. Without any surrounding single quotes in the query's injection point, you're not in a string literal context, you're in a raw SQL context.

SQL Injection is not possible in this situation. This code is preventing SQLi properly and even if the platform is old or misconfigured, it should still be immune to SQLi.

... In a slightly different configuration it maybe vulnerable.

If is_numeric() was removed, mysql_real_escape_string() was replaced with addslashes(), and the server was configured to used the GBK language set, then there is the possibility of a multi-byte attack using the GBK language encoding.

Here's something interesting: The high level in DVWA is not meant to be exploitable. It's the "correct" and safe implementation of the concepts as the DVWA's author saw fit at the time. So, it's very natural that you're unable to perform SQL Injection at the high level. If you actually do, you would be discovering something new. A zero-day, maybe.

I've been playing with DVWA for years and I had to learn this the hard way.