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-si