A possible 4th point: responsiveness. Running JS on the client first for a snappy UI, while concurrently running on the server for storage.
Here’s a HabitRPG example: User checks off a to-do and gains Experience, Gold, levels up, finds a rare item, unlocks new features, etc (it's quite complex). All that happens on the client immediately (including notifications, unlocked <div>s, etc), for a snappy front-end experience. Concurrently, the operation is sent to the server which replicates the actions and stores the results in the database. So here you see both code-duplication-reduction, and improved UI responsiveness.
We achieve this now using browserify to share the code b/w server & client. However, our actual glue-code wrapping client objects to send REST ops, and wrapping server objects to store to mongo, is hideous. Your solution looks cleaner and more robust.
If your app uses a realtime connector (websockets, firebase, whatever) running all post-action updates server-side (eg, EXP GP LVL-up) will bring those changes back to the browser (sort of two-way binding style), so the code sharing situations is less dire. However, you'd still benefit from the fast response time of ops running client-side rather than waiting for the server. But with standard REST apps, the model's post-action updates wouldn't return to the client anyway (unless you asked for them), and isomorphism is a must-have.