What does the GO statement do in SQL Server?

GO is not a part of the TSQL language. It's a batch separator used by SQLCMD and SSMS.

GO is not a Transact-SQL statement; it is a command recognized by the sqlcmd and osql utilities and SQL Server Management Studio Code editor.

SQL Server utilities interpret GO as a signal that they should send the current batch of Transact-SQL statements to an instance of SQL Server. The current batch of statements is composed of all statements entered since the last GO, or since the start of the ad hoc session or script if this is the first GO.

A Transact-SQL statement cannot occupy the same line as a GO command. However, the line can contain comments.

SQL Server Utilities Statements - GO

It originated with the command line interfaces, and persists in sqlcmd to this day. You can write a batch over multiple lines in the command line interface, and the batch isn't sent to the server until you type go.

1> select name, create_date
2> from sys.objects
3> where name = 'foo'
4> go
name                                                                                                                             create_date
-------------------------------------------------------------------------------------------------------------------------------- -----------------------
foo                                                                                                                              2020-07-20 09:56:42.393

(1 rows affected)
1>

You can configure what to use for a batch separator in SSMS. GO is the default, but it can be just about anything else.

It splits the command into individual batches.

For instance, variables' scoped ends with GO.

; separates commands but doesn't end scope.
GO separates batches and ends scope.

You may think of it as if the whole command got split by GO and each part got executed per se.

ie.

This works:

declare @a int;
set @a = 1;
select @a

But this doesn't work:

declare @a int
set @a = 1
GO
select @a -- will throw error as variable is not declared

GO has been well addressed in other answers. Let me add some about semi-colon:

A long long time ago, this wasn't something we used. But the SQL standard (ANSI/ISO SQL) specified that a SQL statement should end with semi-colon. So at a certain version, MS allowed it to comply with ANSI SQL. But it was, and mostly still is, a no-op. I.e., it makes no difference if you have it or not

I wasn't involved when the SQL language was invented (I was a kid), but I can imagine that semi-colon was specified as a statement terminator to simplify parsing of SQL. I.e., when you submit SQL to the db engine, it first has to parse (understand what you said, basically) the statement(s). You can probably imagine that is might be easier for the parsing code in the engine if it could look for some certain character that means "end-of-statement". Hence semi-colon. But as I noted, SQL Server didn't use semi-colon for parsing.

Now, with time, some new language elements that was introduced required that the preceding statement was terminated with semi-colon (WITH as in CTE and THROW being two examples). Without it, SQL Server couldn't parse (understand what you said) and you got a error generated from the parsing phase.

At one time MS said that not ending a statement with semi-colon was deprecated. I.e., they tried to make us believe that at some point in time (some future release), we have to end all our statements with semi-colon. I was probably not the only one who found that a bit amusing - imagine the backwards compatibility aspects! Jumping to present time, if you read the documentation, you find that this is no longer the case (in fact, there are no deprecated featured today - none!).