I agree with user mwalker about the potential problems vector layers have when rendered by web browsers. Since rendering a vector layer is also a CPU intensive task, I would add the following points:
- You cannot expect that general users have a last generation web browser. In fact there are still many instances of the Internet Explorer 6 working.
- You cannot expect that general users have a computer with enough processing power or RAM memory. This problem can become serious when the vector layer has thousands of points.
Besides, I disagree with statements like "Every time map changes map tiles should be recreated and cached if you want to have them quick delivered." Obviously, a map change implies the recreation of the cache, but not the whole cache for the affected layers: just recreating the affected area is enough. In fact, TileCache's seeder (TileCache is mentioned in the linked benchmark) accepts a restricting bounding box parameter.
Another statement I partially disagree is "Those tiles are rendering quickly and they are only 20%-50% in file size when comparing to equivalent raster tiles". In case the vectorial information is packed in a verbose format like GML, this statement can be false. Tiles of vector layers like boundaries that are compressed using formats as usual as GIF or PNG can be very, very light.
At work I have a more pragmatic approach than the almost-always-vector-layers one: a mix of vector and raster rendering. When the shown are area has too much points, pre-rendered, server side WMS tiles, and when the number of points is small enough, client side rendering of vector layers.
EDITION: added 2010-11-10 16h41 CET
Another disagreement the assumption of that getting the vectorial information is faster or, at least, as fast as getting pre-rendered, cached raster tiles. Before the vectorial information arrives client side, (a) the information must be retrieved from a spatial database (PostGIS, Oracle Spatial), ESRI shapefile, file geodatabase or similar, (b) must be formatted (GML, WKT...) and (c) must be sent to the client. In the case of cached raster tiles, neither data source must be queried nor formatting must be done. Thus, it is not clear that vector information will arrive client faster than cached raster tiles, especially when the server is under high load.
EDITION: added 2010-11-10 17:16 CET
The benchmark seem a bit unfair to me: "Mapnik i.e. TileCache was tested as CGI and GIS Cloud vector engine as CGI and Apache module." Why not FastCGI - which has been around for years - instead of CGI? Under CGI, for each new request a new process is created and destroyed at its end. Under FastCGI, persistent processes are used to handle requests, thus each "individual FastCGI process can handle many requests over its lifetime, thereby avoiding the overhead of per-request process creation and termination." Comparing TileCache "under" FastCGI and an Apache module would be fairer.