The idea behind DROP CASCADE is to automatically remove the dependent objects. This is documented on the same manual page that the other answer is referring to:
CASCADE Automatically drop objects that depend on the table (such as views).
(Emphasis mine.)
When you are dropping a table that is referenced by another table, the object that immediately depends on the table being dropped is not the other table itself but the foreign key constraint defined on it.
So, the behaviour you are observing should be expected as it is consistent with the other cases you have mentioned:
DROP TABLE ... CASCADE drops the views that directly depend on the table you are dropping.
DROP DOMAIN ... CASCADE drops the columns that directly depend on the domain you are dropping.
TRUNCATE ... CASCADE is also consistent with the explanation above because it removes rows, and the objects dependent on rows can only be other rows, including other tables' rows – that is why the referencing tables are truncated as well1. 1My only issue with the other tables' truncation is that their foreign keys may be defined on nullable columns and yet the tables are still truncated completely even if some of their rows do not reference the table(s) specified in the TRUNCATE statement. Still, even if it is an inconsistency, it is how the behaviour is documented:
CASCADE Automatically truncate all tables that have foreign-key references to any of the named tables, or to any tables added to the group due to CASCADE.
