The content creation perspective:
RPGs tend to be quite text-heavy so you and your team will spend quite a lot of man-hours writing, proof-reading and maybe even translating the dialogs. It might pay off to make this process as comfortable as possible.
Pure Javascript objects have the advantage that you can more easily integrate functions into your dialog system than with JSON. Also, the syntax is a bit more lax than with pure JSON. Otherwise there isn't much of a difference between the two approaches.
Having the dialog options in a database could be more manageable when you plan to write a specialized GUI tool to create and edit the dialog trees (When your project is going to be very large, this might pay off after all). But when you plan to enter and edit your dialog directly in the database with a general-purpose SQL management tool or even worse typing out SQL queries, you will have quite a hard time ahead of you.
The performance perspective:
Storing the dialogs client-sided could be quite a lot of data which - in the worst case - might have to be loaded all at once when the application starts. That could take a few seconds and also quite a lot of bandwidth.
When you store it on the server, the dialog options will be loaded on demand. That means shorter load-time, but worse responsiveness during the dialogs. A simple tradeoff you have to decide for yourself.
Keep in mind that you can also store your dialog as JSON and store it on the server. You can have the client request individual JSON files on demand with XmlHttpRequest.
The piracy perspective:
When your game runs completely in the web browser without having to rely on any server-sided components, it is trivially easy to pirate. Someone who wants to plagiarize your game just needs to download all the files referred to in the HTML, rebrand it and put it on their own webserver. But when you keep some of your content server-sided, it becomes far more difficult to rip it all.