The short answer: Queries will not be noticeably faster.
The long answer...
If you are doing table scans of 600GB, they needs fixed. And, yes, this type of query will be faster. But nothing else will be faster...
Deleting a bunch or rows will not help performance at all unless you were touching those to-be-deleted rows. If you were not touching them, they would not be in the buffer_pool. That is, after the DELETE, your "working set" has not changed, nor have many of the rows/blocks moved to any better place. So all activity will continue at the same speed.
All you gain by the DELETE is a lot of free blocks that the Operating System cannot see. Instead, they are hiding in ibdata1 or the .ibd file.
I doubt seriously if there is any 'online' option in 5.6 or 5.7 that will free up the empty space and compact the table without doing a full copy and replace. This would cause the table to be locked for a long time. It would not be for 600GB's worth of time, but rather however much is still active.
pt-online-schema-change much make a copy of the table in a piecemeal way so as to not lock for long, and it must use a trigger. Now the value of innodb_file_per_table becomes critical, else you might run out of disk space and/or not recoup the freed space. I strongly recommend =1 before building big tables like this one. If your table is in ibdata1 (CREATEd with =0), you are out of luck at this late date.
Fragmentation in InnoDB is rarely a performance problem, even after a massive delete.
If this purge is based on time, and will be repeated, then you really should have used PARTITION BY RANGE(date). I cover that in detail (including code) in http://mysql.rjweb.org/doc.php/partitionmaint .
But, again, you cannot add PARTITIONs without locking and copying. Maybe pt-online-schema-change will do it, but there could be a limitation.