This is a god damn (pardon) beast of a question with lots of details +1 there. Definitely enough to help people who stumble upon it.

I just mostly wanted to add my 2 cents about not sending physics data!! I honestly can't stress this enough. Even if you have it so far optimized that you can practically send 40 spheres that bounce around with micro collision and it could go full speed in a shaking room that doesn't even decrease frame rate. I'm referring to performing your "delta-compression/encoding" also known as data-differencing that you discussed. It's quite similar to what I was going to bring up.

Dead Reckoning VS Data Differencing: They are different enough and really don't occupy the same methods, meaning that you could implement both to increase optimization even further! Note: I have not used them both together, but have worked with both.

Delta encoding or data-differencing: The server carries data on what clients know, and sends only the differences between old data and what should be changed to the client. e.g. pseudo-> in one example you might send the data "315 435 222 3546 33" when the data is already "310 435 210 4000 40" Some are only slightly changed, and one isn't changed at all! Rather than that, you would send (in delta) "5 0 12 -454 -7" which is considerably shorter.

Better examples might be something that changes a lot farther than that for example lets say I have a linked list with 45 linked objects in it right now. I want to kill 30 of them, so I do that, then send to everyone what the new packet data is, which would slow down the server if it wasn't already built for doing things like this, and it happened because it was trying to correct itself for example. In delta encoding, you would simply put (pseudo) "list.kill 30 at 5" and it would remove 30 objects from the list after the 5th one then authenticate the data, but on each client rather than the server.

Pros: (Can only think of one of each right now)

1. Speed: Obviously in my last example I described. It would be a lot larger of a difference than the previous example. In general I can't honestly say from experience which of those would be more common, as I work a lot more with dead reckoning

Cons:

1. If you're updating your system and want to add some more data that should be edited through the delta, you'll have to create new functions to change that data! (e.g. as earlier "list.kill 30 at 5" Oh shit I need a undo method added to the client! "list.kill undo")

Dead reckoning: Simply stated, here's an analogy. I'm writing a map for someone on how to get to a location, and I'm only including the points of where to go in general, because it's good enough (stop at building, turn left). Someone elses map includes the street names and also how many degrees to turn left, is that necessary at all? (No...)

Dead reckoning is where each client has an algorithm which is constant per client. Data is pretty much just altered by saying which data needs altered, and how to do it. The client changes the data on its own. An example is that if I have a character that isn't my player, but is being moved by another person playing with me, I shouldn't have to update the data every frame because a lot of the data is consistent!

Lets say I have my character moving in some direction, many servers will send data to the clients that says (almost per frame) where the player is, and that it is moving(for animation reasons). That's so much unnecessary data! Why the hell do I need to update every single frame, where the unit is and what direction it's facing AND that it's moving? Simply put: I don't. You update the clients only when the direction changes, when the verb changes (isMoving=true?) and what the object is! Then each client will move the object accordingly.

Personally this is a tactic of common sense. It's something I thought I was clever in coming up with a long time ago, that turned out to be used all the time.

Answers

To be quite frank, read James's post and read what I said about the data. Yes you should most definitely use delta-encoding, but think about also using dead reckoning.

Personally I would instantiate the data on the client, when it receives information about it from the server (something you suggested).

Only objects that can change should ever be noted as being editable in the first place right? I like your idea of including that an object should have network data, through your component and entity system! It's clever, and should work just fine. But you should never give brushes (or any data that's absolutely consistent) any networking methods at all. They don't need it, since it's something that can't even change (client to client that is).

If it's something like a door, I'd give it networking data but only a boolean on whether it's open or not, then obviously what kind of object it is. The client should know how to alter it, e.g. it's open, close it, each client receives that they should all close it, so you change the boolean data, then animate the door to being shut.

As for how it should know what variables to network, I might have a component that is truly a SUB-object, and give it components that you would like to network. Another idea is to not just have AddComponent("whatever") but also AddNetComponent("and what have you") just because it sounds smarter personally.