You technically could do that with ActivityPub (each post has a replies collection that whoever hosts the post can control) and technically can have a client that will refuse to show replies that aren't present there.
Sadly (I think), replies to replies would be under the control of the first replier (as opposed to OP). For that reason I think that every system that has the property you want needs to treat posts and replies as different kinds of entities.
It is used for reply discovery. If you visit a post with your client, your instance will be looking for replies in (a) posts it already knows about (b) that collection.
Re subreplies: it's not a thing you can change later. If you decide that subreplies are simply replies to replies and not controlled by OP, you can't retrofit that later. The reason why I think deciding that only direct replies are moderatable by the post's author is that it creates a weird situation where they might have to choose between moderating out a reply they're fine with and not moderating out a subreply they are not fine with (but the reply's author either is, or haven't noticed yet). We have similar problems in APub already (things along the lines of A blocks B, B sends a post that mentions A, C replies to that post and that reply gets sent to A) that cause people to desire to e.g. block instances because they don't block some other instance, which creates churn, collateral damage (that people might feel wronged by), and encourages all instances to converge to the same moderation policy.
@robryk oh, heh, there you go! I didn't realize there was a replies collection already, surprised it's not used! All of it's definitely possible, just a question of policy-in-software. 😁
These sorts of questions (eg "who controls sub-replies?") are why I tend to prefer minimal standards over maximal ones. It's almost always better to build something and then get adoption and then standardize than the other way around (imho), and often maximal standards have swathes ignored & unimplemented.