Mahesh, I really appreciate your feedback on this. What I ended up doing was disabling the SqlStartUp task that was created by the IaaS SQL extensions and added the action from it as an extra step in my custom startup script task. So, in the end, my startup script will run, then launch the .exe for the extension. My worry about this was if it was possible for the SqlStartUp task to get enabled again automatically causing a conflict again without knowing it. Do you know if that task could be modified and enabled again on its own if there is an update to the extension? We did put these SQL VMs into a maintenance window to only reboot on weekends when necessary decreasing the surface area of SQL having issues upon startup. I also have a script running every 5 minutes looking at the status of the databases to alert if any of them are in a status other than Online.
Since I have my custom startup script, I set both the SQL Server and SQL Server Agent services to be manual rather than automatic. I thought about setting the dependency where SQL server doesn't start until the iSCSI service is available, but I was able to see in the event logs where the iSCSI service started, SQL server then tried to start and then after that the NTFS system checks completed to make the drives available. So as you can see, having that as a dependency isn't foolproof, hence why my custom startup script actually tests writing a file to all iSCSI mounted drives before starting SQL.
I think we found a good solution as long as the SqlStartUp task that was automatically created doesn't get enabled again on it's own.