No, I can't drop the index on the view in production, since it supports a count query that runs thousands of times per minute.

Will look into the FK indexes...

I was hoping that deleting multiple rows in a single statement would improve the overall performance, but deleting 5 rows yielded slightly over 5x the runtime:

Here are the statistics after restoring the indexed view and adding the recommended non-clustered index from the execution plan:

Here are the query stats before and after removing the index on the view:

CREATE UNIQUE CLUSTERED INDEX [IX_AlertsCount] ON [dbo].[vqryAlertsCount]
(
    [EntityID] ASC,
    [UserID] ASC,
    [AlertOwnerID] ASC,
    [PostponedUntil] ASC
)WITH...

Because of this indirect reference, that suggested index may have way more impact than estimated.

I was curious about that as well but then I found the materialized view that references the columns in question:

CREATE     VIEW [dbo].[vqryAlertsCount]
WITH SCHEMABINDING
AS
SELECT...

That table has ~ 62k rows, which is probably why the index recommendation is for there for that table.  Most of the other table are in the hundreds of rows...

A lot of the child tables have very few rows, so I don't think an index on the FK column would have much effect.