Here sample code posted here, where you can see the differences between INDEX and SET FILTER (5 sec) and SET FILTER alone (0.1 sec) :

Its my understanding that Rushmore Optimization cannot work as effectively with SET ORDER TO as it can without it. The set order will far outweigh any benefit gained by the seek.

I built a table with this code...

CREATE TABLE SPEED.DBF FREE ;
(Spd_ID I, ;
Spd_Char C(10), ;
Spd_Date D, ;
Spd_DT T)
LOCAL lnI, lnX, Spd_ID, Spd_Char, Spd_Date, Spd_DateTime
FOR lnI = 1 TO 1000000
SPD_ID = m.lnI
SPD_CHAR = STR(m.lnI)
*This will give me a set of records
*with the same date / date time.
lnX = m.lnI/100
SPD_DATE = {^2000-01-01}+m.lnX
SPD_DT = {^2000-01-01 00:00:00}+m.lnX
INSERT INTO SPEED FROM MEMVAR
IF MOD(m.lnI,1000) = 0
WAIT WINDOW STR(m.lnI) NOWAIT
ENDIF
ENDFOR
INDEX ON SPD_ID TAG SPD_ID
INDEX ON SPD_CHAR TAG SPD_CHAR
INDEX ON SPD_DATE TAG SPD_DATE
INDEX ON SPD_DT TAG SPD_DT
WAIT CLEAR

Then I timed bits of code similar to the ones you posted. I ran this on a local hard drive with 256 megs of RAM and a P3 650.

LOCAL lnA,lnI, Spd_Date
USE SPEED
Spd_Date = {^2027-05-19}
lnA=SECONDS()
FOR lnI = 1 TO 10
SELECT SPEED
SET FILTER TO Spd_Date=m.Spd_Date
SCAN
?SPD_ID
ENDSCAN
ENDFOR
?SECONDS()-lnA

lnA=SECONDS()
FOR lnI = 1 TO 10
SELECT SPEED
SET ORDER TO TAG Spd_Date
SEEK(m.Spd_Date)
SET FILTER TO Spd_Date=m.Spd_Date
SCAN
?SPD_ID
ENDSCAN
ENDFOR
?SECONDS()-lnA

The timing for the first loop is 0.084 seconds and the second is 5.288 seconds. The second loop is significantly slower.