RobertHarvey is totally right: it depends. It could be a good solution but it is a terrible solution also for some projects.
In you question you state:
He has created a small website (there are apparently no dynamic contents)
Based on that he chose the wrong solution. Now you also note that there are animations. So maybe, if those are exceptional, it might be a good solution. Let's state those animation could also be made with normal solutions.
Whether it is good or right is then simple: If it should work like a normal website, so with a good ranking in search engines, good accessibility and all other standard webdevelopers take care of it is just wrong. You build a website with a goal. If that is: Have normal people visit it to subscribe/buy/view etc. it won't meet that goal.
His arguments:
Websites with a high amount of users do this to prevent server overloading.
Yes, but this is a small website right? http://c2.com/cgi/wiki?PrematureOptimization
It is easier to create new sections.
Likely he is unaware of other solutions. No problem, it's his first one. This is something where training / reading could do a lot.
It is easier to translate, as translations, texts and almost everything is loaded from a JSON.
Same here, localisation is something much more complex than just translating some pieces of text anyway. Education is here also the key.
You can expand more sections directly from a JSON file.
Might be correct, seems simple to do. If a user has to do it then it directly becomes more difficult. With a database for example it might be possible to create a form for that.
Everything is smooth, as you don't move to another page.
This is true but not undoable with other solutions. Loading pieces of content with ajax (with changing the browser history) might solve this well. https://developer.mozilla.org/en/docs/DOM/Manipulating_the_browser_history
To take this into a broader level: It is nonsense to build a dedicated framework if it is just a simple site. Use the basics or an existing system for it. On the other side, it's a nice learning experience. We all tried to build a CMS once right? ;) His arguments are not strong, if he want to work more in this area more knowledge would be advisable.
Your Question is going to return some very opinion based answers. So I am trying to answer as neutral as possible regarding which Framework or option to use.
I think every thing you pointed out is fairly modern as are all your listed technologies. jQuery and AngularJs aren't that old I guess.
Also I believe that you have already answered your own question. Let me explain my utterrance in detail :
Out of 3 mentioned practises you don't like 2, so only one mix really remains.
I personally find the mix #1 and #2 ugly
Why not just go with what you are comfortable with for now instead of relying on the opinion of other people. You seem to know what you are doing and have an open mind to new developments in your field so why worry about what other people think for now.
Your question helped me discover something new. Thx for that. Hope that helped.
Originally a comment was just too long for it to be one.
Best Answer
Disclaimer: There are so many other factors in play that your decision on which approach to use should probably not be made solely on this evaluation. Consider team skill sets, long-term maintainability, features needed versus features provided by various frameworks, which client platforms/devices you need to support, and so on. However, from a purely academic standpoint...
Server-side MVC: Server handles data access + building HTML
Client-side MVC: Server handles data access + serializing DTOs
So at first glance, it seems to be a simple matter of which is more resource-intensive, building HTML or serializing DTOs? If building HTML is less taxing than serializing DTOs, then go with server-side MVC. If not, then go with client-side MVC.
But one other factor to keep in mind is the raw number of HTTP requests hitting your server. With server-side MVC, this is likely to be relatively low (typically 1 request per "page"). But with client-side MVC, depending on how you set up your web services API, you could have any number of HTTP requests hitting your server for each "page" in the app. An extremely chatty approach could cause far more server resource utilization from HTTP request processing overhead than from the actual work of either building HTML or serializing DTOs.