Não acredito que essa simples descrição que eu fiz possa ser melhor ou equivalente ao DER, pois nela eu apenas descrevo que a tabela de produtos contém o id do cliente.

Logo, se eu olhar apenas para a descrição da tabela de clientes, eu jamais iria imaginar que existe uma tabela de produtos atrelada a ele. Eu precisaria ler as descricões de todas as outras tabelas para ter ciência de quais tabelas se relacionam com o cliente.

Com o DER, eu consigo olhar para a tabela de clientes e seguir as setas que estão conectadas com ela. E de forma imediata já saber qual o tipo de relação entre a tabela Cliente e a tabela X

Do ponto de vista do programador. Esse tipo de relação, e todo tipo de constraint, ja não deve estar mapeada nas configurações do ORM?

Essa é uma das soluções, mas em meus projetos eu prefiro não depender do ORM para saber como o meu banco de dados está estruturado.
Como citei no meu outro comentário, o simples fato do banco estar visualmente representado, facilita a identificação imediata das relações. Inclusive para evitar dependências ciclicas antes mesmo de começar a escrever o código.

Do ponto de vista do DBA. Dado que a maioria das ferramentas de gerenciamento de banco de dados relacionais (mssql management studio, mysql workbench, dbeaver etc... até plugins do vscode) ja me permitem ter essas informações. Por que alguém deveria se dedicar a manter o DER?

Por enquanto ainda não trabalhei em uma empresa que tenha um profissional específico como DBA e a única interface de banco que eu tive contato foi com o PGAdmin. Nele eu consigo ter uma ideia visual das relações entre as tabelas?

EDIT: Acabei de entrar no PGAdmin e consegui gerar um DER do meu banco. Só ficou meio bagunçado pq ele não posiciona muito bem cada tabela.