It may be regarded as a sort of resource leak. When the application context is refreshed, old bean instances that implement Lifecycle are not automatically stopped. The leakage may occur silently if the application developer is not aware that some beans implement Lifecycle, and simply calls refresh.
If refresh is deliberately not integrated with Lifecycle, then consider it an error condition to call refresh on a context before stopping it.
At minimum, please improve the documentation around behavior of Lifecycle beans and context refresh.
Indeed, Lifecycle beans aren't necessarily receiving a stop() signal before destruction. If a stop point is essential for resource management in a specific bean of yours, consider implementing DisposableBean with clean-up in destroy(): This is generally advisable anyway, since the destroy call will arrive in any scenario, even aborted refresh attempts etc. Such a destroy call will also be called after stop on regular shutdown, so it needs to be prepared for both kinds of scenarios, cleaning up what's left.