This is an issue that I noticed adding Teradata's REPLACE VIEW syntax, as I had to decide between putting it in the CreateView or the AlterView objects.

CreateView has the syntax
CREATE [OR REPLACE] VIEW
while AlterView has the syntax (after my modification)
(ALTER | REPLACE) VIEW

Since view replacement is part of CreateView, it has a meaning that is duplicated with AlterView.
Most SQL syntaxes, e.g.

Teradata
https://docs.teradata.com/reader/VrFCOAaniAIfrJsA51oQJA/70Hc7UuiM6I9L~07Nkr6YQ
SQL Server
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql?view=sql-server-2017
https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-view-transact-sql?view=sql-server-2017
mysql
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql?view=sql-server-2017
https://dev.mysql.com/doc/refman/8.0/en/alter-view.html

have a syntax which is identical after the prefix tokens.
Therefore, any change to CreateView must be propagated to AlterView, and vice versa, to keep them in sync.

I see that the CreateView syntax supports a WITH clause, this seems to be from SQL Server.
But in SQL Server, ALTER VIEW can also have a WITH clause.
So the syntax support for CREATE/ALTER VIEW has already diverged.

There are two possible solutions.

1. Drop the AlterView object, and merge its parsing into CreateView
2. Add comments with explicit warnings in the CreateView and AlterView object definitions, .jjt parse code, and deparser code that the codepaths for the two statements must be kept in manual sync.

Option 2 is preferable if you think that CREATE VIEW / ALTER VIEW can have significant;y different syntax in future updates, for example Cloudera:
https://www.cloudera.com/documentation/enterprise/5-14-x/topics/impala_alter_view.html
https://www.cloudera.com/documentation/enterprise/5-14-x/topics/impala_create_view.html

If you agree, I can implement a pull request with the preferred option (1 or 2, adding WITH support to AlterView).