A hierarquia original dos níveis de inodes funciona mais ou menos assim:
Você pode armazenar um ou alguns números de bloco diretamente no inode. Isso significa que você usa alguns bytes a mais para o inode, mas para arquivos pequenos, não é necessário alocar um bloco completo, que está quase vazio.
O próximo nível é uma indirecção: você aloca um bloco para armazenar os ponteiros de bloco. Apenas o endereço deste bloco indireto é armazenado no inode. Isso não usa de alguma forma "menos espaço", e a maioria dos sistemas de arquivos, mesmo os primeiros, funcionava assim (ter um ponteiro próximo ao inode / filename que aponta para um bloco, que armazena os números de bloco do arquivo).
Mas o que você faz quando o espaço neste bloco se esgota? Você tem que alocar outro bloco, mas onde você armazena a referência a este bloco? Você poderia simplesmente adicionar essas referências ao inode, mas para armazenar arquivos maiores, o inode ficaria grande. E você quer pequenos inodes, de modo que o maior número possível de inodes pode caber em um único bloco (menos acesso ao disco para ler mais inodes).
Então você usa um bloco indireto de dois níveis: Você apenas adiciona um ponteiro ao inode, então você tem um bloco inteiro para armazenar ponteiros para blocos indiretos, e os blocos indiretos armazenam o endereço do bloco do próprio arquivo.
E assim por diante, você pode adicionar blocos indiretos de nível mais alto ou parar em algum estágio até alcançar o tamanho máximo de um arquivo possível com a estrutura desejada.
Portanto, o ponto não é "usar menos espaço no total", mas "usar um esquema que use blocos de forma eficiente para a distribuição esperada de um arquivo, ou seja, muitos arquivos pequenos, alguns arquivos maiores e muito poucos arquivos ".
As tabelas de páginas, por outro lado, funcionam de maneira muito diferente.
Editar
Para responder às perguntas do comentário:
Blocos de dados são de tamanhos fixos (originalmente 512 bytes, IIRC), que é um múltiplo do tamanho de bloco dos discos rígidos subjacentes. Então, o tamanho do bloco de dados não pode "diminuir".
Como tentei descrever acima, todo o sentido de ter os inodes não ocupando muito espaço é tornar o acesso do inode mais rápido (ou, alternativamente, fazer inodes do cache consumir menos memória então, quando o sistema de arquivos unix com inodes foi inventado, os computadores tinham muito menos memória do que hoje. Não é não que de algum modo economize espaço no total. Como você mesmo diz, tudo tem que ser armazenado em algum lugar, e se ele não usar espaço no local X, ele usará espaço no local Y.
Apenas adicionar um número variável de ponteiros de bloco ao inode não é prático, porque o inode deve ocupar uma quantidade fixa de espaço - você quer usar o número de inode para calcular o endereço do bloco e o offset dentro do bloco onde o as informações do inode são armazenadas. Você não pode fazer isso se cada inode tiver um tamanho diferente. Então deve haver alguma forma de indireção.
As tabelas de páginas funcionam de maneira diferente porque o hardware as implementa de maneira diferente - é assim mesmo. A hierarquia tem uma profundidade fixa, sempre a mesma (embora algumas vezes configurável. E, embora a leitura de um bloco do disco seja lenta, isso não importa para as tabelas de páginas. Portanto, os problemas de design são completamente diferentes.