INSERT with ON CONFLICT does not insert rows as expected
I see an elephant in the room:
... and deleted_date is null

There can be rows with non-null deleted_date, which are ignored by your test with  SELECT but still conflict in the unique index on (feed_id,feed_listing_id).
Aside, NOT IN (SELECT ...) is almost always a bad choice. Even if it's not going to break completely with all NOT NULL columns in your case, it still typically delivers bad performance. See:

Select rows which are not present in other table

Use NOT EXISTS instead:
SELECT * 
FROM   listing_master  m
WHERE  feed_id = 'ddf' 
AND    NOT EXISTS (
   SELECT FROM listing 
   WHERE  feed_id = 'ddf' 
   AND    feed_listing_id = m.feed_listing_id
   AND    deleted_date is null                 -- ?????
   );

What's more, even with deleted_date is null out of the way, this expectation of yours is strictly incorrect:

... while it clearly should add 136 of them.

You only tested for feed_id = 'ddf'. There can be any number of additional rows with a different feed_id. So it would be &quot;at least 136 of them&quot;.

If that's not it, we need to talk about possible concurrent write access. Related:

Concurrent transactions result in race condition with unique constraint on insert
How to use RETURNING with ON CONFLICT in PostgreSQL?

Or possible index corruption. In this case the cure would be:
REINDEX INDEX listing_feed_id_feed_listing_id_idx;