The original question seems to conflate the underlying platform and the application built upon it which can be thought of, in some cases, as an overlay network and often has its own access control concerns.
As you know, a public network is generally organized so that anyone who follows protocol can attach a node. By extension, that means node operators are pseudo-anonymous and accountability will be weak while censorship-resistance will be high. In many contexts accountability is a desirable thing and there may be no good reason for the general public (non-members) to access the network, e.g. a B2B network for a consortium of trading partners.
Great. So, given a context and set of requirements, the appropriate network topology should be approximately self-evident.
Application-level concerns still exist and they are not addressed with precision by network topology alone. Consider that everything-to-everything TCP/IP networks are populated by applications that do indeed authenticate users and categorize them according to privileges. To say that another way, nothing about the Internet's open architecture implies that everyone can anything. And, there are valid reasons for private networks that are not reachable from the public network. The same applications can often run in either context - internal web-based app and external public-facing web site.
It is very common for a system of smart contracts on the Ethereum public network to restrict access to sensitive functions to the owner/deployer, an admin, or something more granular. Standard libraries like OpenZeppelin's Ownable, Whitelisted and Role-based Access Control implement such patterns in Solidity.
Such patterns can re-introduce degrees of centralization, intentionally or accidentally, because only specific authoritative users can do certain things. This can lead to a governance consideration at the application level. Who should decide? Is that a single user or a committee? How does the committee decide?
So, there are platform-level concerns and they imply certain things about what's going on. Ethereum means everyone can see, while Quorum's private transactions mean certain parties can see, Hyperledger Fabric's channels mean messages go to groups of nodes and Corda networks work on a need-to-know basis. When working with private networks, one can expect to spend considerable time working out a topology that doesn't advantage or adversely disadvantage the intended participants. One will spend more time on that because of the flexibility offered.
As with any platform, the choice of platform implies certain low-level properties of anything one builds and concerns for the applications one constructs, so it is wise to select the right platform, but, application-level concerns still exist. Access control will still be a concern on a function-by-function and message-by-message basis.
You can create centralized points of control in contracts on Ethereum's public network. One of the key concerns when designing a system is where to vest the trust, especially if a decentralized design is desired. Indeed, when auditing contracts one of the key concerns to look for is elements of the contract logic that might give certain users non-obvious advantages. For example, if a contract can be paused by the owner, immutability has been compromised and users should be informed about that possibility.
Hope it helps.