I've always assumed the benefit is that you don't have to maintain a separate set of files for each window size... but it seems like, for all intents and purposes, you might as well be if you have to set up special cases for all sorts of window sizes, just in one document.
Yeah I guess what I mean is you should always aim for DRY but who says the code reuse has to happen on the client? Why not do at least some of the necessary changes based upon screen size upstream on the server if it reduces complexity? My guess is this is probably harder for designers than hacking on CSS. I don't buy the argument that it's more or less DRY depending on where the reuse occurs. The only argument is that there is some value in having the browser understand the layout more fundamentally, but the only use case this enables is the "resize to mobile size on my desktop computer" case, unless I'm missing something.
It's pretty DRY as you'll only be writing media queries for the parts of the site that need to change. Many times you don't have to write MQ's for everything. Writing completely different sites like you mentioned earlier would be/has been a hassle to maintain as opposed to a site that was originally designed as responsive from the onset.
The use case that someone might come to your site on a tablet, laptop and/or phone is a pretty common use case nowadays. Designing and maintaining one site to cover all of those is the goal. Simple MQ's to shift to each one is much easier to maintain than an entire other codebase.
One reason for choosing client over server: richness of data that can be queried. Media queries allow you to test for all sorts of features [1] which may be difficult impossible to test on server, e.g. color depth, pixel density etc.
