While I am not aware of your goal and willing to add/develop more hardware, I am also on the need for a tachometer that would not rely on interrupts. The VCO option well discussed already here is good, but it depends on the precision you need for this reading. Say, if you want to show it on a dashboard, 100rpm error would be quite enough for an efficient visualization.
Now, if 1 RPM change is of importance for the matter, then I would say don't use a VCO.
If you would use interrupts (ok you don't want to), critical sections of your code can have interrupts disabled. See, for 6500RPM the interrupts frequency would be 108Hz, an ISR with a couple of tests and a variable incrementing or so could be very fast; but let's let this aside.
You know, the option of counting to 256 bits (or whatever
X value you wish) would yeld a variable cadence of readings, and if visualization is an issue, this will have negative impacts. If the thing is at 128 rpm you would take 2 minutes to get a reading...
You always will have to live with an expected error (precision if you will). I was thinking myself by adding a counter chip, with a timing sampling controlled by the arduino, that would constantly read the count (SPI, or if you have spare I/O, parallel reading, etc.) then reset it. Say every 300ms, 500, 1s, I don't know it is usually dependant upon the aplication. then you read it and use the value. You could also define a timer for it I think.
Another option, add to it a latch (a hardware buffer) that is constantly updated by the counter circuit, that can also run with a clock generator and be completely standalone. The latch would be constantly updated. and the sensor would be always working. Then when you wan't to know the RPM value, you would just read it on the latch, via SPI (serial), or other method.
It all depends on a cost X benefit scale that should consider your need for performance, data precision, cost, complexity.
If you (sorry if I didn't see it on this thread) state "I wish do build a diesel engine tachometer that will present the value in an LCD, and I also need to compute some other info such as engine temperature, oil temperature, some other light/sensor), then maybe we could also help you to determinate the ranges and precisions involved and reasonable. For a car tachometer as an example, 200rpm scale is quite enough. So why add complexity and try to measure 5rpm steps or so? You may not even get this precision in the sampling... Then you would be able to decide better the solution for it.
One thing learned is that you should not start thinking in HOW to solve/build a thing, before letting your mind fly high, brainstorm, and project that mars rocket of you. After you know exactly what you want to build, then you begin to think how and eventually cut out the expensive/non practical parts of it. Or else, your project will start already being limited more than it should, and you may not see solutions for it.
If you already know all that you wan't to do, maybe sharing it a little more could help us to help you best.
Of course if we are talking about intelectual property and business or so, at least some more detailed info should be presented.
-Quick interrupts, with critical sections of the other functions disabling interrupts (for 66.667 Hz I think that an 8MHz risk processor won't loose an interrupt, unless you let yout "other codes" to sleep) to avoid disruption as mentioned. Or even the interrupt may not be so intrusive as you suppose (or you have tested, or have real data figured out about the interrupt impact?)
-VCO (freq to volts converter) - depending on the precision needed, I think is the simplest approach. Also, there are lots of commercial dirty cheap chips to do that, no need to build one)
-External counter. This would add the trick to read the count either by serial or parallel.
Hope I have helped to figure it out a little more. Lissandro :-)