I'd be curious as to a description of some of the specific revenue and cost saving advantages.

Sure no problem, the first and foremost that I can think of would be self contained widgets for third party sales channels. Lets say I sell hotel rooms. I can build a JavaScript widget that provides rates and inventory in a small list on the side of a page. A related sales site can then just drop it on their site, by adding a div with a certain CSS class assigned to it and it instantly giving me a direct sales channel where there was none. At little to no integration cost to them. So with that widget, I can implement a pretty robust affiliate sales channel. I could do the same with a static image or HTML as advertisement, but having real inventory and prices available is going drive up conversion. Thus it could be said to be a new channel of revenue.

Second would be in certain usage patterns, there are some usage patterns that when you have to submit a page back to the server for every step it becomes cumbersome and requires significantly more code. Lets take a grid for example, say I provide a list of items in a grid and I want that information to be sorted in one of several ways. With the old model of spitting it back to the server I have to hold on to a bunch of info on the server, and generate several views to re-sort it. With a JavaScript grid, I just have a couple of custom sort functions that I pass into the sort method on the array and then re-bind the results to my grid. So what would necessitate 5-6 different views generated by the server, I can manage with just a call to array.sort() the grid can observe the array.sort() and react to it being called. In these kind of multi-path UI workflows not round tripping to the server reduces a good deal of complexity from the system.

For me personally I think getting rid of SP (ASP, PHP, JSP) leads to a more maintainable system, because I think it is simpler. Having the UI and workflow concerns as a separate application that is delivered to the browser helps deal with a lot of Anti-patterns that the SP development model introduced. I prefer to write my front ends disconnected from the server and have their only connection be for data and business processing. I feel that it reduces the complexity of the solution and that it separates the concern of the workflow of a system from the processing of a system nicely. Some will differ on that and some will be more productive in the SP's. For me and the team I work with, we can deliver more compelling apps faster using JavaScript as our UI languadge. As well, I like the fact that the server architecture forces everything to be implemented behind addressable interfaces. It makes going to Mobile or other platforms as simple as creating a new work flow tailored for that specific device. JavaScript applications have evolved to take advantage of what the web is becoming. More and more people are implementing workflows never originally conceived of on top of unrelated back end systems. Taking services from Facebook, and Yelp or twitter etc. and implementing totally novel and new concepts, even if they are wholly unrelated to the companies that provide the services. This was not possible when UI's and data where locked, together, behind proprietary server technologies like the SP's. To me that is the greatest advantage, it provides a UI platform for an internet where all services are available as a collective platform. The entire web becomes the platform and anyone can write a workflow on-top of it.

As for useless features implemented in JavaScript I would say we had the same issue with Flash, just because you can does not make it the reason to do so. All I can speak for are the effort that I am part of and when we embark to build something we try to back it with real business need. Some people don't seems to put as much emphasis on not wasting time and money and I don't see that changing whether it is just a static web page, JavaScript or any other technology.