I'd actually keep the loop=None parameter and add something like this:

if loop is not None:
    raise TypeError(
        f'passing explicit "loop" argument to {type(self).__name__}() '
        f'is no longer necessary')

I thought that we should fully remove loop parameter because it deprecated.

Maybe it's better to fully remove loop as for me it a lit bit confusing to have a parameter that raises an exception when it set, it looks the same as we won't have loop parameter when it set we will receive an error that init method doesn't accept loop but it has a drawback - exception message won't be such explicit.

What is your opinion?

We could do marker=object() and then use the loop=marker default to make it better. But I'm also not 100% about my own suggestion here :) @asvetlov thoughts?

I'm +1 for raising an explicit error and using the sentinel approach to check if the user passed a loop arg. Especially with how widespread the loop parameter is used throughout existing asyncio code, it's going to be a much smoother transition to have an error message that tells users precisely what they did incorrect rather than the parameter just disappearing.

(Also keeping in mind the unfortunate reality that not everyone tests with deprecation warnings on, or might not have gotten around to removing loop throughout their own code since the warnings started in 3.8)

As for when the parameter should just be removed entirely without an explicit error message, I think doing that in 3.11 or 3.12 would be fine.

Now I get it, sorry that didn't understand it the first time.

Give an explicit error will be better for debugging and will make the transition much easier.
I will update #23499 to use this approach regarding the loop parameter.

Although I would make the message a little bit more direct and technically specific:

if loop is not None:
    raise TypeError(
        f'As of 3.10, the *loop* parameter was removed from {type(self).__name__}() ')
        f'since it is no longer necessary')

loop=marker looks a little more protective but, I think, the whole idea is a slight overcomplication.
For me, "removal" means exactly removal but I can live with the proposed change.