Your surprise is justified, since identity is a property fixed at column creation that ALTER COLUMN genuinely cannot toggle off, so removing it means recreating the column's data without the property, and there are two routes by how much disruption you can accept:

Why there is no direct ALTER: the identity property is part of how the column was defined at creation and SQL Server provides no ALTER TABLE ALTER COLUMN syntax to add or remove it, a real limitation rather than a syntax you are missing. So every method is fundamentally about getting the data into a column that lacks the property, which is why it takes more than one statement.

The new column route, least disruptive for a live table: add a new plain integer column, copy the identity column's values into it with an UPDATE, drop the old identity column and rename the new column to the old name with sp_rename. The data survives, the property is gone and the table stays largely available, though you must handle any constraints, indexes, foreign keys or defaults on the original column, recreating them on the new one, the fiddly part that makes this careful rather than trivial.

The SELECT INTO route, cleaner for a rebuild: SELECT * INTO NewTable FROM OldTable creates a new table without the identity property, since SELECT INTO does not carry identity unless you use IDENTITY() deliberately, then you drop the old table and rename the new one or better, being explicit about the schema. This rebuilds the table fresh but requires recreating all indexes, constraints, keys and permissions the original had, so it suits a table simple enough or a maintenance window that allows the rebuild.

The practical choice and caution: for a column on a busy table with dependencies, the add new column and rename route within a transaction is usually safest and for a simpler table a clean rebuild is fine, but either way script the table's full definition first, its indexes, constraints and foreign keys, so nothing is lost in the recreation and do it in a transaction with a backup, since removing identity is a structural change that touches the table's integrity machinery. The reverse question, adding identity to an existing column, has the same no direct ALTER answer and the same recreation solution, the property being a creation time decision either way.