FTP is actually a lot older than HTTP and therefore wasn't developed as an alternative. Traditional, multi-socket FTP actually has massive disadvantages in today's firewalled, NATed internet. HTTP is more useful than FTP or most other protocols for transferring individual files these days. I've never worked with WebDAV, but it seems like it would be a preferable alternative almost anywhere you might use FTP.
As an example where HTTP doesn't work so well, is pushing information as opposed to servicing requests. COMET is a hack and requires you to be very careful with clients. (e.g. the 2 connection limit in older browsers) You'd only really want to use it where there's no alternative, like in a browser.
Basically, HTTP is great for servicing individual requests. It can do kind of do persistent connections, but they're more an optimisation than part of the design and therefore optional for the client even if the server suggests them.
If your use case falls outside of the basic request/response premise, you can maybe use it for prototyping for a while, but you should probably switch to something more suitable to your setup after that unless you need to use HTTP for reasons outside of your control.
As an example where HTTP doesn't work so well, is pushing information as opposed to servicing requests. COMET is a hack and requires you to be very careful with clients. (e.g. the 2 connection limit in older browsers) You'd only really want to use it where there's no alternative, like in a browser.
Basically, HTTP is great for servicing individual requests. It can do kind of do persistent connections, but they're more an optimisation than part of the design and therefore optional for the client even if the server suggests them.
If your use case falls outside of the basic request/response premise, you can maybe use it for prototyping for a while, but you should probably switch to something more suitable to your setup after that unless you need to use HTTP for reasons outside of your control.