HomeOne:/srv/www/lighttpd/homeone# php ./test.php
The preincrement loop took: 15.85929107666 seconds.

The postincrement loop too: 16.909289121628 seconds.

The difference is: 6.6207123628175%

I ran this a number of times and got values ranging from 4-6%.

4-6% != 21%

It's great that you have taken the time to prove that there is no practical difference between a for() loop and a while() loop. It's always worthwhile double checking to make sure your guesses are correct. What this shows is that you should write your PHP for readability and maintainability and use code profiling tools afterwards to optimise only where it is needed.

You could spend weeks rewriting all your code to use do…while() loops instead of for() loops and end up saving a grand total of a minute of CPU time each day. If you had spent the same time using XDebug you would have realised that 90% of the page generation time is spent in mysql_query() calls and you should have been optimising your SQL or caching the results.

When I find code that is causing problems because it's taking too long, it is usually something like a for() loop that iterates over an entire database table and discards 90% of the rows where it would be much more efficient to rewrite the SQL query to only return the 10% of the rows you actually want. Sometimes it's a snippet of code that writes and reads from the same database table, meaning that when you have lots of instances of this code running, they all have to wait for the table to be unlocked. (MyISAM can't do concurrent reads and writes) Sometimes it's PHP writing to a file over an NFS mounted directory that several webservers all write to.

When you're optimising code, run benchmarks, run profiling tools and pick the low-hanging fruit.

…and seriously, who would use date("U") instead of time() ?

Re: Point six:
What exactly are you testing? Are you incrementing one variable ten million times, or incrementing one value a million times? Or a range of values a million times? A benchmark of iterating from 1-1,000,000 isn't accurate because no-one is ever going to do that- PHP's designers wont have optimized the language for that.
Going from 1 to -1,000,000 will be different from 1,000,000 to 1 because the underlying data type has to be changed from unsigned to signed, which has a memory overhead.
Specifying whether the var is an int or a float will make a difference. I would also imagine that there will be different data types used for larger numbers (floats, doubles, reals etc) which will each have different performance characteristics.
The test is only meaningful if it is done with a realistic scenario.

Re Point 7:
As the manual gracefully points out; preg is most often faster than ereg in any case. It's actually quite a useful thing to have around.