Uma razão para os inodes serem fixos é que no formato tradicional do sistema de arquivos Unix (o qual, por exemplo, o ext4 ainda segue bem de perto), os inodes são armazenado no que é essencialmente uma única tabela . Com itens de tamanho fixo, localizar um item com base em seu número de índice é trivial. Com qualquer outra estrutura de dados, seria necessário mais trabalho e, talvez mais importante, mais leituras de acesso aleatório na estrutura de dados.
O tamanho do arquivo em si não influencia o próprio inode, que tradicionalmente armazena a localização dos primeiros blocos de dados. Para arquivos mais longos, o sistema aloca blocos extras (blocos indiretos) para manter os locais no restante. (Veja a página da wikipedia para uma bela foto.)
Eu disse "tradicionalmente", desde O ext4 realmente faz as coisas de maneira diferente, ele pode salvar o conteúdo de links simbólicos no próprio inode (eles são geralmente curtos, então é útil não alocar um bloco inteiro), e a árvore tradicional de blocos únicos é substituída por um caminho de extensões , ou seja, extensões de vários blocos.
Tanto quanto eu posso dizer, no ext4 a razão para suportar inodes maiores que o tamanho mínimo, é permitir que novos campos sejam armazenados e usar o espaço extra para atributos estendidos. Observando a tabela no primeiro link, os campos extras acima dos 128 bytes originais em um inode ext4 armazenam principalmente carimbos de hora de maior precisão. Nos sistemas SELinux, os rótulos de segurança são implementados como atributos estendidos, portanto, poder armazená-los diretamente no inode pode ser muito útil.
Novos sistemas de arquivos como o btrfs, o XFS e o ZFS com formatos menos ortodoxos provavelmente farão as coisas de maneira diferente, e eu não sei muito sobre os sistemas de arquivos usados, digamos, sistemas BSD.