> Over a duration of about 15 minutes, it appears as if 2798 rows have
> "disappeared" from the table. The primary key simply jumps from
> 3561297 to 3564095. During the same time period, I've got debug logs
> from clients of this API which indicates that something went wrong
> during the request. My IIS log notes that any request which causes
> database access during this time period had taken between 30000 and
> 40000 ms to complete.

I don't think the rows have disappeared.  

Your debug logs show that something went wrong during requests to the database when the gaps happened. If queries are aborted & rolled back the identity values will not roll back with it.

Another example is that the application has a timeout window of 30 seconds. Queries that take longer than that will be cancelled and the insert will be rolled back.

As mentioned earlier, in the case of rollback, the identity value allocated will not be rolled back. Instead, the next identity value in line will be used when retrying the insert.

 There could have been other reasons that the insert was failing, such as network loss, inserting values that would be truncated, wrong datatype conversions, ....


Below is a reproducible example that shows two gaps:

    CREATE TABLE dbo.identitytable(id int identity(1,1), val varchar(255))
    INSERT INTO dbo.identitytable(val)
    VALUES('BLA1');
    
    GO
    BEGIN TRAN
    INSERT INTO dbo.identitytable(val)
    VALUES('BLA2')
    
    ROLLBACK TRAN
    
    GO
    
    INSERT INTO dbo.identitytable(val)
    VALUES('BLA3')
    
    GO
    
    SELECT * FROM dbo.identitytable
    
    GO
    
    INSERT INTO dbo.identitytable(val)
    VALUES(REPLICATE('B',256));
    GO
    
    INSERT INTO dbo.identitytable(val)
    VALUES('BLA5');
    
    
    SELECT * FROM dbo.identitytable;

With the last select producing a result with two gaps:

    id	val
    1	BLA1
    3	BLA3
    5	BLA5


If an insert with multiple rows is rolled back then the gap will be bigger too:

    BEGIN TRAN
    INSERT INTO dbo.identitytable(val)
    SELECT 'BLA6'
    FROM master..spt_values
    ROLLBACK TRAN
    
    
    INSERT INTO dbo.identitytable(val)
    VALUES('BLA7');
    
    
    
    SELECT * FROM dbo.identitytable;

Result

    id	val
    1	BLA1
    3	BLA3
    5	BLA5
    2546	BLA7



[DB<>Fiddle][1]


> But how can a transaction rollback occur, if I do not execute a BEGIN
> TRANSACTION? I thought TSQL only made "auto transactions" if
> IMPLICIT_TRANSACTIONS was set to ON?

Queries without `BEGIN TRANSACTION` or without the "bad idea" `IMPLICIT_TRANSACTION` setting enabled are auto-committed transactions in itself. 

When canceling/aborting the modification of data due to the reasons specified above, undoing these changes have to be done at the database level. This is done via a rollback. If this did not exist, your data would be in an incorrect state.


 

  [1]: https://dbfiddle.uk/?rdbms=sqlserver_2017&fiddle=bf57483db16cc77d24fadc5873a64117
  [2]: https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/