Yes, there are cases when you may specify
COPY, but it would be for other reasons than performance.
It is important to understand that MySQL introduced new feature - Online DLL processing in version 5.6. It did not remove offline processing. So there is a need to differentiate between these 2 modes:
Some operations still work in Offline mode only. See Table 15.10, “Summary of Online Status for DDL Operations” for a list of the DDL operations that can or cannot be performed in-place.
Operations in Online and Offline modes have slightly different behavior, so you can choose "old" one for compatibility reasons.
Some examples (please suggest more):
InnoDB tables created before MySQL 5.6 do not support
ALTER TABLE ... ALGORITHM=INPLACE for tables that include temporal columns (
TIMESTAMP) and have not been rebuilt using
ALTER TABLE ... ALGORITHM=COPY. In this case, an
ALTER TABLE ... ALGORITHM=INPLACE operation returns error.
ADD PRIMARY KEY clause in
COPY mode silently converts
NULL to default values for that data type (0 for INT, empty string for varchar), whereas
IN_PLACE does not do that.
With the ALGORITHM=COPY clause, the operation succeeds despite the
presence of NULL values in the primary key columns; the data is
silently changed, which could cause problems.
Another reason to prefer
Operations for which you specify ALGORITHM=COPY or old_alter_table=1,
to force the table-copying behavior if needed for precise
backward-compatibility in specialized scenarios.
Although MySQL manual doesn't talk about actual scenarios, you can imagine some. E.g. developer relied on table being locked during
ALTER INDEX operation so table is read-only or fully locked and there is a process that reads static table during index rebuild.