In SQL Server, what's the impact of a checkpoint to log records in log buffer?
We could implement a DBMS such that every thread that needs to write a log record writes it straight to disk immediately and waits for acknowledgement. This would be inefficient since there would be many small IOs and many threads waiting. It is more efficient for each thread to write to an in-memory buffer and have that buffer written to disk as a single large IO. All threads that write log records add to this one buffer and when it is written to disk (i.e. &quot;flushed&quot; or &quot;hardened&quot;) all log records from all threads are written.
So when must that buffer be flushed? There are three mandatory circumstances

When a transaction commits.
When a checkpoint is taken.
When the buffer is full.

The system can additionally write the buffer any time it chooses. The
Log records must be flushed before a commit acknowledgement is sent to the client to satisfy the durability guarantee of ACID.
Checkpoints flush dirty pages from the bufferpool to disk, whether the transaction which dirtied those pages has committed or not. On restart after failure the DBMS needs a way to figure out which changes to those dirty pages should be retained and which removed. SQL Server follows the ARIES recovery protocol for recovery and ARIES requires the write ahead log to be flushed before the dirty pages are flushed.
Naturally the buffer must be of finite size and so the system must be able to empty it at any point. The log contains many types of record other than user data changes. ARIES protocol takes care of the various combinations of flushed log, flushed or unflushed bufferpool pages, and committed, uncommitted and rolled back transactions.
The authors you quote are saying the same thing - that log records must be flushed before the corresponding dirty pages can be flushed. This is an echo of the documentation linked previously

SQL Server has logic that prevents a dirty page from being flushed before the associated log record is written.