The TFA correctly lists many sins with architecture diagrams, but misses the proverbial forest over metaphorical trees.

IMO the mistakes mentioned in these diagrams stem from them actually being component diagrams disguised as architecture diagrams.

While the astute would be technically correct in calling component diagrams a type of architecture diagrams, focusing on components is what typically leads to diagraming mistakes. Component diagrams are really useful when determining what competencies, licenses/subscriptions, etc. are required when for example evaluating fit of project inside of an existing ecosystem.

However, when managing the system or making changes to it, you rarely care whether data is stored on S3 or local minio cluster, because at an interface level S3 merely a protocol. Yet, you do care about data dependencies and control boundaries.

A component diagram may easily just connect application backend to S3-compatible storage component and call it a day, however in a full architectural diagram you would really want to see where e.g. the auth thingie comes from.