There are tons and tons of use cases for sharing code between server and client. Why would you want to write things twice? The only reason it is not more common is that programming is generally done in different languages on the server and client.

I built an ebook reader that can process ebooks in javascript. Because IE does not support the File API the server needs to pick up the slack when users are on that browser. Sharing code means I don't need to program two versions and I only have to patch bugs once.

It's also common to share validation code. This allows you to check data client-side and then again once it reaches the server using the same code.

Off the top of my head:

Data types - Both concrete classes or helpers for manipulating data.

Input Validation - Do it client-side to do it fast, but double check on the server.

Formatting - Larger web apps often need to format things from dates to users to numbers on client-side generated data without the server hop.

Templates - Many templating systems are compatible with multiple languages, but its easier if there's just one output type.

I just built and launched https://popbasic.com/. It shares the router, controllers, actions and templates between the client and server. I have the "frontend" that runs client and server which then talks to an api.

It works pretty good because i can serve out a full page request (good for SEO and fast load times) then boot the same application on the client so subsequent navigation is fast.

Very, very rarely. Along with "now you can get your frontend developers to write backend code!", it's one of those oft-cited but spectacularly bad reasons to start using JavaScript for non-client stuff.

In saying this, I use node for a heck of a lot at work, but that's mostly because some of the workflows available (streams and events specifically) are perfectly suited to the programs I write in it; not because it lets jQuery monkeys crank out substandard backend code.

Even if never, the idea is to reuse skills, not code. (In the same way that you reuse little code from Rails apps when build Chef recipes)

That's not entirely true - you can reuse some libraries between client and server-side: underscore's utility functions are the underpinning for many node modules, sizzle and jQuery is great for DOM parsing when writing screen scrapers, etc. There's browserify if you want to run node modules in the browser.

Not sure though. But top of it you would probably use backbone.js in both server and client. Another advantage is we have UI developers who are now writing server code to be much more. To some level it is giving a path way for one language everywhere paradigm. However, server side coding required much more capabilities like performant code, scaling etc., but for normal websites it is easy to go with node as it kills some amount learning curve.

My situation was different to this, but when sharing C# between a backend server and an iPhone app I found it tremendously useful to use the same models, and just JSON encode/decode them to transmit between the two.