Load Testing When SQL Server Caching Is Disabled
Your tests are flawed.  Your data sizes are too small to produce any meaningful results.  CHECKPOINT/DROPCLEANBUFFERS after every query is giving results that would never correlate with reality.

As for your questions:


Assume a simple query run in a loop:

UPDATE questions SET up_votes = up_votes + 1 WHERE id = @id


This query will generate a small transaction log entry for each query, and dirty the page it hits.  If you update the same row 1000 times, you could generate 1000 small transaction log entries with one 8k write (at some point later).  If you issue a CHECKPOINT, you will force the dirty page to be written to disk after every query (at least 1 additional 8k write, maybe more depending on indexes).  The DROPCLEANBUFFERS will force the next query to issue multiple 8k reads. (the data, the intermediate index levels, GAM pages, SGAM pages, PFS pages, etc, etc, etc)  


No.  Even if you have a 500 GB database and 8 GB of RAM, a lot of meta-data and intermediate level index pages will remain in memory and are critical for performance.
See above about GAM/SGAM, etc.
CHECKPOINTS will generate a trivial amount of additional log activity.  You are still squarely in the "background noise" range with your data volumes to evaluate log growth in any meaningful fashion.  


As an analogy, It is like attempting to measure the gas mileage in a vehicle just by backing out of the driveway.

If you are concerned with SAN performance, then look into Microsoft's DiskSpd.exe tool (formerly SQLIO).  The documentation has sample configurations that relate to known SQL Server access patterns.