Thanks @lopuhin for the idea. I'm sorry that I'm against it.
The "returned" values (or to be precise, the feature of returning values via the StopIteration exception) as introduced in PEP-380 are not for yielding values from the generator, that's for returning a value from subgenerators to the delegating generator.
Sample code and the result: link
I don't doubt at all that we're technically able to somehow intercept the process and force such values to be picked by Scrapy, just as normal values from the generator. But that doesn't look like the right thing to do to me.
Suggestion: If close() is not to return a value, then raise an exception if StopIteration with a non-None value occurs.
While I agree that it is something we shall not have at the language level, I think it beneficial to check for such cases for only request callbacks within the scope of Scrapy, as I assume such mistakes may have been bothering some people for some time already.