Não existe isso de ser fácil de prever. Quem acha que isso é que dá segurança não entende de segurança. Você dá acessa às pessoas ao que elas têm autorização para acessar, o resto não é para ela ter acesso, portanto se a pessoa prever algo e ela não pode acessar e o sistema foi feito por quem entende de segurança não há problema algum. Se ela acha que é melhor um ID longo para dificultar, está no jogo do tigrinho, até o invasor vai perder quase sempre, mas uma hora ela acerta.

Dados sensíveis só devem ser acessados por quem tem direito a isso, ponto. Se só tiver um dado e o ID dele for 1, ele só deve ser acesso ao autorizado, qualquer pessoa que tente usar 1 para acessar não vai conseguir, simples assim. Mais uma vez, segurança não é contar com a sorte, quando a pessoa fala em ser menos previsível ela já está admitindo que ela aceita que sorte a foda se a alguém tiver virado pra lua ou achar uma técnica nova que aumente as chances de acerto. Quem faz isso deveria ser proibido de fazer softwares profissionais.

É óbvio que existem casos que você precisa de um ID de acesso aberto para qualquer pessoa que o possua, mas isso costuma ser temporário e é exceção, é mais um ID de acesso do que um ID de banco de dados, ainda que seja aproveitado para isso (muitas implementações não usam o mesmo, preferem um ID para o DB e outro para expor publicamente). Reforço, não é a mesma coisa que estão falando aqui, é outro tipo de ID.

Boa parte dos IDs públicos gerais são justamente para acesso de qualquer pessoa, então não existe isso de previsibilidade nesses casos.

Se puder use um ID sequencial simples. Quase todos os sistemas podem. Até alguns sistemas que fazem cadastros de forma distribuída podem usar assim e na maioria dos casos, a centralização garante bem o funcionamento e o custo é de ter que esperar o efetivo cadastro para ter o ID no cliente que está fazendo o cadastro, o que geralmente fica na casa de poucos milissegundos, se muito, ou é possível fazer uma reserva (isso tem lá seu problema quando a pessoa desiste do cadastro, mas tem diversas soluções).

Se realmente precisa de um cadastro distribuído (poucos sistemas realmente precisam disso) naquela tabela, então precisa usar um ID gerado dentro um certo padrão. Atualmente o ULID parece ser o mais adequado para isso, mas não tenho experiência prática. Se o espaço for um grande problema pode se usar uma variação do Snowflake, mas geralmente não é uma ideia tão maravilhosa porque só tem problemas com espaço quem tem muito cadastro e o risco de colisão aumenta. Não podemos descartar, mas quanto mais complicado é o ID, mais restrições de uso ele tem, menos deve ser usado por quem tem pouca experiência com engenharia de software.