Do you have a rationale for why you prefer fail to drop? If the user intends to drop a column and SQLite says you can't because of x,y and z, then the user has to manually do that work anyway. Why make them jump through the extra hoops? To me that is like asking the user to manually delete triggers before dropping a table.
There is however at least one situation today where DDL does result in an inconsistent schema: the first table of a circular foreign key reference. Ideally that would only be allowed inside a transaction and rejected at COMMIT time unless resolved by additional DDL statements. But that doesn't seem to be the case.
Similarly, perhaps one could imagine wanting to change a column type, leaving the rest of the schema alone:
BEGIN;
ALTER TABLE t ADD COLUMN x1 $NEWTYPE;
UPDATE t SET x1=x;
ALTER TABLE t DROP COLUMN x;
ALTER TABLE t RENAME COLUMN x1 TO x;
COMMIT;
It would possibly be annoying to have to recreate all views and triggers here. In that case an immediate dropping of related views and triggers would not be so useful. But then neither should the DROP COLUMN command fail before the surrounding transaction commits.