Steps to reproduce
configured: edited hide.php with parameter for class/hide_date
configured: DelayedIndexing enabled

Before hide

browse to object in front end and visible [Good]
search for object using solr and object found and visible [Good]

Alter hide Date field for scheduling

edit content object's hide_date for 10 minutes from now
send for publishing
wait for 10 minutes

Run hide.php and validate

command line> run php runcronjobs.php frequent
command line> hide debug shows object being hidden [Good]
browse to object in front end and object is hidden [Good]
search for object in front end and object is VISIBLE [BAD]
click solr result link and object is hidden - shows solr is out of sync

From what I can tell the functions involved are

eZContentObjectTreeNode::hideSubTree()
ezContentObjectTreeNode::updateAndStoreModified()
eZContentObjectTreeNode::clearViewCacheForSubtree( $node, $modifyRootNode );
and
eZContentObject::clearCache();

I don't see any code that queues the ezfind index in there.

Please confirm that hide.php is DelayedIndexing safe

I would expect something like this in the hide.php (pseudo code)
$solrSearch->updateNodeVisibility( $node->attribute( 'node_id' ) );