I think boolean flags are a code smell. Let's add a new method called addSqlStatement() instead?

You mean, like a static constructor method ob Query?

No, I mean like a new method next to addSql, called addSqlStatement.

protected function addSqlStatement(
        string $sql,
        array $params = [],
        array $types = [],
): void {
    $this->plannedSql[] = new Query($sql, $params, $types, true);
}

This implies that this is an SQL query, but for some reason we want to execute it as a statement. Apparently, it's the opposite: https://stackoverflow.com/questions/4735856/difference-between-a-statement-and-a-query-in-sql

I would create a parent class called Statement to model this better, and then use instanceof.

Well, the hard part being that even though queries are statements in the understanding of SQL in this SO answer, this is not entirely true for the DBAL API.
If you use executeStatement to execute a statement that returns a record set (i.e. to execute a query), some drivers will fail due to receiving a non expected record set. For instance, PDO only supports having 1 buffer at a time for record sets, so you must consume or close the result of a query before executing another query: #888 (comment)

Also, DBAL (and also the ORM) seem to use Query as the more generic name (see QueryBuilder as name)

Still, it feels weird to leak a DBAL implementation detail in the public API of this value object, or even for that value object to have knowledge about it.

According to the SO answer, queries are statements, and not the other way around. According to DBAL, queries and statements are different things (so would be best modeled as 2 classes extending a common one I suppose?).

Also, DBAL (and also the ORM) seem to use Query as the more generic name (see QueryBuilder as name)

I don't think Doctrine\ORM\Query and Doctrine\ORM\Query\AST\*Statement can really be compared if that is what you are referring to, and how the ORM treats one as more generic as the other.

As for QueryBuilder… I guess it's badly named (although it's a mistake I could have made myself before today)? Other parts of the DBAL don't seem to treat query as the more generic name (otherwise Doctrine\DBAL\Statement would not have that name). Anyway, if there is a naming/modeling mistake in other packages, I don't see a huge benefit in mimicking it for the sake of consistency. It's IMO fine for doctrine/migrations to have its own model of statements and queries, to fulfill its own purposes, regardless of whether it's using DBAL or another API.

I suggest we model the SQL standard instead of mimicking the DBAL API, that way the Query class is not modeled after a lower-level API, but against a higher-level, common abstraction that the DBAL also knows about: SQL.