The additional delay is coming from a new implementation of the search update pipeline, which has a deduplication window. In principles, search is an asynchronous system and should not be used in a synchronous workflow. Our informal and undocumented (yet) SLO is that updates should be visible in 10 minutes.

It might be time to review how we use search in the edit workflow and find alternatives.

This is hugely disrupting my workflow. What could the alternatives be, do an API call on (X) new items created by the user?

I'll let @Lydia_Pintscher give more context on the future plans and workarounds. We will be working on a prioritization of Wikidata updates in the search pipeline, but it will take some time. In the meantime, it should be possible to refer to items by their QID.

We've discussed how to go about this problem some more. Here is the option we have come up with so far to address the problem of using the asynchronous service for synchronous work: We could have some form of local storage for the user that contains the entities they recently created. Those would be used for suggestions when making new statements.
Additional thoughts:

• One interesting step in this direction is allowing to create a new Item directly from the statement editing UI. @Celenduin has created a user script to explore how this part could look like and the details are in T107693.
• People have said that it would not just be interesting to use this local storage for the recently created entity of the user but any they have recently used. This would make some edits easier where you repeatedly use the same entity while editing many entities.