If you know how costly this is, why didn't Frontier know and ditch the offline idea from the start?
i can only speculate, but based on my own experience during large software development projects, sometimes things just come up! (i'm not trying to sugar coat). i'll try to give an example.
you know how with some websites (Facebook and Google+ are good examples) the site appears to "auto refresh", meaning new content keeps coming into the page even when you're not actually interacting with it, you're not clicking or whatnot? this is done using a persistent connection between the browser and the site/servers. this is not "normal HTTP" traffic as HTTP traffic does not maintain any kind of state.
so if you want to make a website that auto refreshes content for your users, you have to use a technology or protocol on top of regular HTTP. there are many different options to do this, some more complicated than others. the barrier to entry for some of them is much higher than others. so at some point, the software architect has to make a choice of which one to use, based on information they have at the time. so they make a choice, and go with it.
the code is written, tests are done, QA is completed, and everyone is happy. yay!
down the road however, lets say a new feature is added, unfortunately this feature is more 'expensive' on the wire than you had previously anticipated. suddenly the protocol that sits on top of HTTP that was 100% totally fine before, may not be fine anymore. suddenly instead of using a periodic XMLHTTP long polling request just won't cut the mustard anymore. you have to reevaluate the situation, realising that you might (for example) have to use persistent TCP websockets instead of sitting on top of HTTP.
so in order to carry on and keep giving your customers the performance that you promised them, you have to rip out your long polling code and start using websockets. this could be a significant amount of work. you didn't want to use websockets to begin with, but "various things have come up" that are effectively forcing your hand.
now you have to add another month of dev work, plus 2 weeks of QA to your project timeline (slowing down other things) so you can refactor your network code to use websockets. this has happened to a project that i was writing backend Go code on very recently. the type of hyper-fast speedy interactivity we needed a particular site to have was just not performing well enough using long polling, so we had to rethink and go with websockets. it sucked as i really liked the longpolling code that i'd done.
the site was slightly delayed, the client wasnt happy, but after explaining our thought processes, the pros and cons of each approach, a happy medium point was arrived at.
my feeling is that this is exactly what happened with ED offline mode. i suspect that during the initial phases of development, quite a lot more of the core game mechanics was being performed on the client side. but as development progressed, as more features were added, it became clear that having these processes performed on the client side was just not optimal. or perhaps they were not as easily scalable on user's PC's as they would be if they were performed at the server side.
i suspect they tried to work around these issues, trying different methods of solving the problem(s), but ultimately (and again this is conjecture on my part based only on my experience of large software systems) the hard decision was made to move these items into the server side.
its a decision that noone likes, neither FD, nor many of the initial backers who really really wanted offline mode. FD's devs are obviously extremely good at their game (no pun intended), i mean look at it! if it was possible from either a staffing, financial or project-scope perspective to keep offline mode, they would have. i am convinced of this. but, for reasons that are obviously opaque to us (internal development decisions are generally not made public), the hard decision was made and [poorly] communicated to us as backers.
it's sad, i for one will miss the offline mode (though not as much as many others it seems). but this is NOT a decision that FD made lightly. and this is almost certainly NOT something that they knew of many months or even years ago as some have suggested.
complex things come up when developing complex software. sometimes very hard decisions have to be made. sometimes "all of the things" simply cannot be quantified from the beginning of a project. its only when thousands of players start interacting with your system(s) that you can "grok" how things may pan out. this is why we are all part of a BETA. to help test. to help FD quantify. in-house QA testers can only give so much data.