Por que você declararia um tamanho de campo maior do que os dados reais que espera armazenar nele?
Se a versão inicial do seu aplicativo for compatível com endereços dos EUA e Canadá (o que estou deduzindo do fato de você chamar esses tamanhos em sua pergunta), declararei o campo como VARCHAR2 (9) (ou VARCHAR2 ( 10) se você pretende armazenar o hífen nos campos ZIP + 4). Mesmo olhando para as postagens que outras pessoas fizeram nos códigos postais de vários países, VARCHAR2 (9) ou VARCHAR2 (10) seria suficiente para a maioria, senão todos os outros países.
Abaixo da linha, você sempre pode ALTERAR a coluna para aumentar o comprimento, caso seja necessário. Mas geralmente é difícil evitar que alguém, em algum lugar, decida ser "criativo" e coloque 50 caracteres em um campo VARCHAR2 (50) por um motivo ou outro (ou seja, porque eles querem outra linha em uma etiqueta de envio). Você também tem que lidar com o teste dos casos limites (será que todo aplicativo que exibe um ZIP manipula 50 caracteres?). E com o fato de que quando os clientes estão recuperando dados do banco de dados, eles geralmente estão alocando memória com base no tamanho máximo dos dados que serão buscados, e não no comprimento real de uma determinada linha. Provavelmente não é um grande negócio neste caso específico, mas 40 bytes por linha podem ser um pedaço decente de RAM para algumas situações.
Como um aparte, você também pode considerar armazenar (pelo menos para endereços nos EUA) o código postal e a extensão +4 separadamente. Geralmente é útil ser capaz de gerar relatórios por região geográfica, e você pode querer frequentemente colocar tudo em um CEP em vez de dividi-lo pela extensão +4. Nesse ponto, é útil não ter que tentar SUBSTR out os primeiros 5 caracteres para o código postal.