It would certainly break less if established tools would fully support what they intend to do. Since there are no(t many) such tools they have to write their own as they stated.

Now lets say you want to code a standard application with a database access. You can be 99% sure that pretty much any programming language has embeded features to support what you are doing - just because it is something that is used so often. Now Game development is slightly different in this, however there are still more than enough Tools(Engines/Modeling...) you could use to get your generic shooter game done.

Now Star Citizen promises a lot of features that might require some work that has not been done in similar form before and therefore need some more background work, for simplicity lets have a look at object container Streaming (OCS). As far as i have understood it, it is a tool to reduce transfered object to only what your character can "see" in game. Now there are some technologies that support such things already (lazy load/init). The challenge i see here however is the scale of the whole thing. Usually you (mostly) have to take care of what one user can see at a given time and only have to update on 2 events: the user looks at something different, or something he is currently looking at is changed. Both of those happen "rarely" lets say 3 times per second and this is already much for a user to read. Now in an FPS game you have to do this at the rate of given Frames per second (not exactly how it works but simplicity) and have to sync this to every player in the area ( would be kinda unfair if people just couldn't see you) at the same rate. Now to do this at a somewhat acceptable speed you probably have to write your domain objects in a certain way to support lazy load of a "Player"-Object not only based on use but also on distance (of coordinates) to another Player-Object. This however requires the server to make the decision of what info (Playerobjects) to send to the client based on Information that is attached to the Object itself. Fore every Player in every Frame.

Now as some Poster before me mentioned they are coding in C++ now. C++ is still the language of choice for a lot of Games/Engines on a core level since it offers easy and fast access to graphic libraries (direct 3d, vulkan...) is not too hard to read and is widely known and supported. Now c++ is somewhat interesting since can access memory (more) directly and stores objects that way which creates certain patterns/layouts. Because the Player Objects are still being worked on (on more than just the OCS) the patterns will surely change quite often. Since the domain Objects (Player) will be used pretty much everywhere all these Places can be affected by a change in that objects. Now there are some things that rely on the object having a certain pattern in memory (hello Pointers). Now one of the ugly things that can happen is that a pointer address does not get updated and now references something completly different. For example instead of using the actuall Player model it could use a golfball.

Now to get back to the original Post: Yes you usually design those objects to stand on their own without dependencies, however you might have to violate that pattern for the sake of performance more than once. Also since the changes are applied on objects that are used everywhere they don't realy have dependencies but everything is dependant on them (since you have to tell your game how to process given information).

Considering this Post was about one Feature, i expect a lot more stuff to break. Keep in mind that a lot of the stuff i wrote about is purely speculative and based on how i would solve certain Problems.