I absolutely think there's value in prototyping to explore business opportunities, or to evaluate choice of technology. I think problems arise when you try to do both at once.
Also, once the business gets hold of a prototype, it can sometimes be hard to convince them to pay to replace the prototype with a new codebase which seemingly does exactly the same thing; after all, what they've got works, right? (For some definition of "works".)
It can also be difficult to work out exactly what needs to be kept from the prototype; how do you tell what functionality is intended, and what is just a non-essential byproduct of the implementation? Yes, you can formalise the specification, but this takes time, and customers will complain about any changes to functionality.
You'll be served in good stead if you pick a tech that can support all the normal boring stuff that a robust web app needs, while also providing rapid development capabilities.
Also, once the business gets hold of a prototype, it can sometimes be hard to convince them to pay to replace the prototype with a new codebase which seemingly does exactly the same thing; after all, what they've got works, right? (For some definition of "works".)
It can also be difficult to work out exactly what needs to be kept from the prototype; how do you tell what functionality is intended, and what is just a non-essential byproduct of the implementation? Yes, you can formalise the specification, but this takes time, and customers will complain about any changes to functionality.
You'll be served in good stead if you pick a tech that can support all the normal boring stuff that a robust web app needs, while also providing rapid development capabilities.