The reason that you can't do it on a table referenced by foreign keys is that since it's done at the page level without regard to rows it is not possible to action the CASCADE, SET NULL, SET DEFAULT, or NO ACTION (= throw error) actions specified by the foreign key constrain as these have to be done at the row level. So allowing TRUNCATE on the referenced table would effectively say that the constraint wasn't a constraint at all because it wouldn't constrain anything. It's nothing at all to do with it using drop-create, which is not what it does.

In fact drop-create would be a rather silly implementation method for truncate, since the metadata for all check constraints, default constraints, and indexes would be destroyed by dropping the table and would have to be recreated, all views referencing the table would have to be dropped before dropping the table and recreated after recreating the table, metadata for indexes on those views would be destroyed and would have to be recreated, the same goes for views referencing those views and so on recursively, so potentially quite a big recreate script would have to be built as part of the dropping process (all this would be new code, as drop table doesn't currently have to do any of it) and stored somewhere and run, risking making truncate rather slower than it should be as well as a pretty nightmarish thing to try to implement.