I think web app developers should use the most appropriate technology for their apps. If you know the data schema upfront and you are not concerned about evolving that schema or about ingesting data from other places with different schemas then stick with a relational database. Otherwise you should consider using a triple store. Be aware though that triple stores are at the stage relational systems were back in the early eighties. They don't have the advantage of 20 years of optimisation (or 20 years of feature creep). They also have only a fraction of the ecosystem of tools, users, forums, blogs, community knowledge, experience etc that systems like Oracle have. However you may find that the flexibility and expressivity that a triple store gives you vastly outweighs those disadvantages.

I cannot give you a better answer than the pragmatic answers already given - 'Use what works and what is appropriate' - but I can say that I use RDF to encode data, but I don't use a triplestore to hold it.

For me, a triplestore is useful when I want to query the data in a way that I'd find hard with other systems. But for simpler tasks like 'what is the human-readable label for URI X', I use a key-value db (was a normal db, now Redis) to do that simple lookup.

... evolving that schema or ingesting data from other places with different schemas

This is for me also the main issue. If you answer yes to that, and are a Python-developer, than I would suggest this recent thread on the rdflib mailing list as a practical starting point.

You should choose whatever is appropriate.

Traditional relationship data structures can't always answer your domain problem as outlined in this talk from the WindyCityRails Conference:

http://windycityrails.org/videos#3

I tend to think that it would be good to store the semantic data in the triple store, but to leave it to individual apps to decide how to use the data. This means that if you have the processing need and capacity, you can use triple stores and all the semantic goodness, but if you have a very thin flash client, you might just want to emit the data to a backend, which can then serve rdf late.