There are good reasons ALGORITHM=INPLACE may not be used and switches to ALGORITHM=COPY.

REASON #1

In the link you gave in the question, there is a chart that shows the following:

• Adding a FULLTEXT index trigger a table copy is not supported for online operation
• Many operations can revert to copy because it says in the notes Although ALGORITHM=INPLACE is allowed, the data is reorganized substantially, so it is still an expensive operation.

Some online DDL may still lock and copy because of an index's interaction. Don't forget that each BTREE entry in a secondary index has a hook back to the primary key. Adding a new secondary index may induce row level locks and index locks.

REASON #2

According the limitations page : InnoDB tables created before MySQL 5.6 do not support ALTER TABLE ... ALGORITHM=INPLACE for tables that include temporal columns (DATE, DATETIME or TIMESTAMP) and have not been rebuilt using ALTER TABLE ... ALGORITHM=COPY.

I am sure there are other reasons that can be researched an discussed along these lines.

There are too many different cases. I suggest you read https://dev.mysql.com/doc/refman/8.0/en/innodb-create-index-overview.html , then come back with a more specific question. (Back up the version if you are using something older.)

My feeling in watching MySQL evolve over the years is this last round of Optimizations of ALTER has added ways to speed up just about everything in ALTER. That includes avoiding rebuilding the table (when practical) and avoiding locks (when practical).

"says mysql can dml when modify column" -- Well, that depends on the modify column -- add/remove NULL, change ENUM / DEFAULT / etc, ADD/DROP, etc.

The first ALTER optimization was for adding an option to ENUM at the end and not exceeding 255. That was added many versions ago -- It was rather trivial in that it changed the "meta" data only. That can even be INSTANT in the new 8.0 terminology (even better than INPLACE).