Thing is, if it just guesses what you meant instead of sticking to the standard, you can end up with ambiguous meanings. Like what if you forgot a character that wasn't a semicolon but inserting a semicolon would turn it into valid code?

Like:

x = y z++;

Inserting a semicolon would turn that into set x to the value of y and then increment z. But maybe the line is missing a plus instead of a semicolon and the intent was to set x to y plus z and then increment z.

It's a pain but strict syntax helps avoid frustrating to debug bugs.

Taking it a step even further, you can make your code more robust by treating warnings similarly to errors. Even though the general cases usually still work despite warnings, they are great for avoiding edge cases that can also be difficult to debug. At least if you take the time to understand what the warning is really about and don't just google "how to get rid of warning x" and add some casts or something you don't understand to make the message go away.