In general it's a defense-in-depth thing. You definitely shouldn't be relying on it, but as an attacker it just makes your life a bit harder if it's not straightforward to work out object IDs.
For example, imagine you're poking around a system that uses incrementing ints as public identifiers. Immediately, you can make a good guess that there's probably going to be some high privileged users with user_id=1..100 so you can start probing around those accounts. If you used UUIDs or similar then you're not leaking that info.
In gitlabs case this is much less relevant, and it's more fo a cosmetic thing.
In my experience self-hosted GitLabs are rarely publicly-accessible in the first place; they're usually behind some sort of VPN.
As for an attacker being able to iterate through users, if that information is supposed to be private, and yet an attacker is getting anything other than a 404, then that's a problem in and of itself and my energy would be better spent fixing that.
This is again a defense in depth thing. In the age of WFH, cracking a corporate VPN is really not that difficult. If you can make an attacker's life harder for low cost you should do it just in case.
Except you ain't really putting up a meaningful obstacle against an attacker here. Compared to the typical effort of cracking a corporate VPN, brute-forcing IDs is downright trivial.
Like I said elsewhere: it's like calling ROT13 "defense in depth".
For example, imagine you're poking around a system that uses incrementing ints as public identifiers. Immediately, you can make a good guess that there's probably going to be some high privileged users with user_id=1..100 so you can start probing around those accounts. If you used UUIDs or similar then you're not leaking that info.
In gitlabs case this is much less relevant, and it's more fo a cosmetic thing.