Per quanto riguarda il ragionamento alla base della numerazione specifica, che non corrisponde a nessun'altra architettura [tranne "x32" che in realtà è solo una parte dell'architettura x86_64]:nei primissimi giorni del supporto x86_64 nel kernel Linux, prima che esistessero seri vincoli di retrocompatibilità, tutte le chiamate di sistema sono state rinumerate per ottimizzarle a livello di utilizzo della cacheline.
Non so abbastanza sullo sviluppo del kernel per conoscere la base specifica di queste scelte, ma a quanto pare ce ne sono alcune logica alla base della scelta di rinumerare tutto con questi numeri particolari piuttosto che limitarsi a copiare l'elenco da un'architettura esistente e rimuovere quelli inutilizzati. Sembra che l'ordine possa essere basato su quanto comunemente vengono chiamati, ad es. leggi/scrivi/apri/chiudi sono in primo piano. Exit e fork possono sembrare "fondamentali", ma ciascuno di essi viene chiamato solo una volta per processo.
Potrebbe anche esserci qualcosa nel mantenere le chiamate di sistema che sono comunemente usate insieme all'interno della stessa riga della cache (questi valori sono solo numeri interi, ma c'è una tabella nel kernel con puntatori di funzione per ognuno, quindi ogni gruppo di 8 chiamate di sistema occupa una riga di cache da 64 byte per quella tabella)
Vedi quella risposta alla domanda "Perché i numeri di chiamata di sistema sono diversi in amd64 linux?" su Stack Overflow.
Per riassumere:per motivi di compatibilità, l'elenco delle chiamate di sistema è stabile e può solo crescere. Quando è apparsa l'architettura x86 64, l'ABI (passaggio di argomenti, valore restituito) era diverso, quindi gli sviluppatori del kernel hanno colto l'occasione per apportare modifiche che avevano atteso a lungo.