Valid point. I should have noted in the article that in our case, we assume our clients to have javascript enabled. As a startup, you have to be willing to let go of some customers to provide a compelling experience to others.
I totally agree with you. Even as a not-so-startup any more (we've been around for 11 years now). It really depends on the type of your customers: If you are selling a specific app to them, you might more easily get away with JS only than if you are producing a page for general consumption.
But, of course, if you go the JS only route (which I have done for my tempalias.com fun project last year), then you also have to keep in mind that you will be duplicating model code and dealing with two separate ORM layers:
One on the server for the API itself and one on the client which gets used by the GUI controllers. Backbone can be of help there, but if you want to, say, do some validation logic already on the client without the roundtrip, then you begin duplicating logic on both server and client.
So how ever you put it, going JS only is probably more work in the end, but it's also less work than going the traditional way and then bolting on a fully-fledged API because the lack of dogfooding it will cause you trouble once you get real users for it.
Overall it's a really difficult decision to make and it's also quite final as changing the direction, again, means a lot of work.
Personally I think it depends on the scale. As soon as you have actions that can't easily be implemented in server side code or have a large divergence in possible behaviour for clients, you can say "you need javascript to view this" (pretty much, when it can be called an application).
I find the 'javascript to enhance' guideline helpful to. Then sites are more likely to be functional (but not pretty) in older browsers. A good example is javascript to make menus slide, but which use CSS to make them come up.
