First of all, you need to know that Windows Azure SQL Database is a multi-tenant, high-density RDBMS offered as a service. That means, that a single server is used by possibly hundreds of customers.
I also suggest that you get to know the SLA for the services, Windows Azure SQL Database in particular. Noone has ever claim that there will be 0ms latency. There is also such thing as "Transient Conditions" in WIndows Azure SQL Database.
A good suggested reading is the Windows Azure SQL Database Performance and elasticiy guide.
As for web application performance, after reading the Performance and elasticity guide, I don't think the 200ms that happens once in a while are the core bottleneck.
UPDATE after the first comment
You will always have ups and downs in a shared environment. You should also expect query execution times to change up and down. This is unavoidable in that kind of environment and something you have to design for and live with. There is no magic wand here, and there is no dedicated server for you (for us) in the case of Windows Azure SQL Database. If you think that you app needs more reliable SQL Server services, you might try the Windows Azure Virtual Machines and bring up a SQL Server cluster by yourself. I guess ( and this is only a guess) that the communication between your cloud service and your VMs, given everything is in the same availability set, will be more predictable.
Update after 2nd and 3rd comments:
Well, yes, you might have licensing issues (I'm the expert on licensing). Is the ticket you have opened for the ups and downs? If so, you may try to escalate it (don't know how, but you have your ticket ID, you must also have an assigned engineer and an e-mail about the ticket - reply-to-all to that e-mail). Also, when you created the ticket there must have been a small questionnaire to reflect the business impact of your issue. Then a usual response time must have been assigned to the ticket. If the support has not come back to you within that time, you can definitely escalate it.
UPDATE
Interesting observation that I have is that in all your screenshots only the first packet is delayed, then every consecutive has 0 latency. In all the samples you are providing. If this is your case 10 out of 10 times, then you are definitely not having any issues with latency. I will suggest that you use the "-t" option in the regular ping to send more than 4 packets and observe. I suggest breaking at around 100 packets, and then observe the results. I would not take into account 4 packet samples, where only first one has latency for any performance reviewing.