I’ve never seen a distro that didn’t grant read permission to everyone for /sbin and /usr/sbin.

In any event, it doesn’t really make sense to me to deny read access for any executables, so long as you don’t also deny read access to Python or a C compiler.

Really, if permission mode bits are the only thing preventing damage from such tools your vulnerability is not within your path or mode bits.

Yep, it's not relevant. If you click through to the change proposal, you will see their reasoning.

Meh. I'm not bothered whether they're merged or not then. All these folders are administered by rpm anyhow.

Uhhhh, more than rpm exists. I fail to see a problem that is solved by merging them. I guess some fresh project manager with nothing to do believes they found some low-hanging fruit to get their name on something. ¯\_(ツ)_/¯ It's a waste of time to reinvent this wheel. It will probably make things worse. Many of these ideas come from folks who started with something other than a *nix and are trying to make things feel more like home rather than understand why things are the way they are.

Not really, that can still be done without permissions. You WOULD be able to stop them from knowing the files are there if you remove read permissions to others, but I haven't seen this done.

The main advantage I see of having them separate is that you can remove sbin from user's $PATH to avoid confusion.

Outside of what the article itself says, even while I was managing large multi-user Linux installs that wasn't really a concern we had. At this point the benefits and concerns are minimal.

Read the linked change proposal.