The sp_start_job system stored procedure is executed asynchronously. For example, executing a job that will execute for five hours, using sp_start_job results in an immediate return of control back to the caller while the job continues to run in the background.
Although this is desirable in several scenarios, there are some reasons why an end-user or process would want to wait synchronously for control to be returned after executing sp_start_job.
In my customer's situation, they have a centralized SQL Server Agent job that executes two steps sequentially. Each step exeecutes a job using sp_start_job. The first step is used to initiate a database backup operation. After the database backup operation is completed, the second step is to wait for the backup to finish, and then kick off a network backup of the database backup device.
Because sp_start_job runs asynchronously, they have to manually create a "listener" job step to loop until the job status is complete. They would rather have the option to wait synchronously for the database backup operation to complete prior to completing the job step, and then move to the next job step in the SQL Server Agent job depending on success or failure.