Sqlite is an in-process database, which means that its performance characteristic is going to be similar to a well optimized application that uses a file to store data.
In an IaaS or PaaS cluster, an Sqlite website can be infinitely scaled out extremely easily for small, read-only sites. Simply deploy a new application server with a copy of the sqlite file, and when the workload dissipates, simply dispose the server. Updating such site can be done by applying a simple rolling update to the server cluster. In this kind of scenario, and especially when the sites handles lots of complex read-only queries, sqlite can be much faster and simpler to scale than traditional database as there's no serialization/inter process communication involved in each query.
This also makes sqlite very well suited as a secondary database for a stateless application server to store the mostly static configuration, historical data, and pages that are rarely changed on a whim.
Sqlite can handle multiple writers very well, much better than most other in process database, but as a fundamental limit to in process database, all the writers must be in a single machine. This limits your application to write workloads that can be handled comfortably on a single machine. If your application has fairly small number of writers, sqlite can usually handle them well. While it is possible to deploy an sqlite site with the static file in a networked file system, networked filesystem often don't have correct implementation of more advanced filesystem features like flock, flush, or shared memory that are necessary to ensure transactional correctness and good performance, which makes deploying sqlite site with multi-machine writers on a networked filesystem a rather tricky business.
Most smaller and medium business web sites which acts simply as an online presence/business card, containing little more than some information about the company's people, product, and contact info and probably small contact form are very well suited to sqlite site. These sites typically have very low frequency of updates and a single server can comfortably handle 10k page views per day which is way more than enough for these type of sites, so simplicity of maintenance is a very important consideration. Sqlite can serve these scenarios very well, as you can update the site simply by copying the sqlite file over from development and backup the site by scp-ing the sqlite file to somewhere else.