RCE by definition always involves the network, but to me the "network" part isn't the problem, it's the "code execution" part that's the problem, and that's a problem with the vulnerable application which is reachable over the network, not the ability to talk on a network.
As a case study, browsers confer to HTML/JS apps the ability to make a wide range of network requests directly from a user's computer. This has been used in practice for RCE in conjunction with a vulnerable service.
Does this mean we should treat network access as RCE and say... build an exec() feature into browsers which would allow JavaScript programs to run arbitrary code?
I hope you can see how these two things aren't equivalent.
I'm bringing up conditional compilation in the context of my very similar proposal, which I made a few days before yours (that said I'm still glad you're thinking along the same lines):
Namely, I proposed leaning on cargo features as the fundamental modeling dimension for "permissions". You are proposing a completely separate mechanism.
I think using cargo features for this purpose not only provides reuse of an existing mechanism, but also provides for a simpler, more flexible solution which works for both std and crates alike which nicely answers questions like "if we grant permission X, doesn't that also transitively grant permission Y?".
Using conditional compilation as the mechanism by which these dependency relationships are gated means if we ever get them wrong, programs won't compile. In this way, it's not possible for side effects/ambient authority to "sneak in" via logic bugs (other than bugs in the "cargo feature" conditional compilation logic, which is hopefully fairly robust at this point).