Because the changes that you have made *may* may not have flushed (written) to the database.
I believe that we all including shmuelb,are aware of the fact,
that the query don't returns the deleted objects anymore once we call flush.
I think the real question is following:
why does hibernate query not filter the deleted object from the result set anyway?
This question is eligible, as Hibernate does iterate the result-set anyway before returning it to the user.
Hibernate must iterate throug the result-set (except projections and scalar queries) because it tries to match entity objects of the result-set with the ones already present in the persistent context.
This to guarantee:
1. object identity within the persistent context (see http://docs.jboss.org/hibernate/core/4.0/manual/en-US/html/transactions.html#transactions-basics-identity
2. simulate repeatable-read isolation behavior
(if entity a was already present in your context (=first level cache) with a.name='beta'
then it will remain 'beta' even if the result-set returns the record relative to instance a with name = 'alpha')
It would therefore be a tittle for Hibernate to do also check the state of the matched entity objects in this context.
So why Hibernate query does return objects in deleted state?
I guess the answer is given by following counter-arguments:
1. A query without flush also don't considers new instances (instances created in current transaction),
so why it should indeed recognize deleted instances?
2. Scalar results and projections would return different results than normal queries:
A aa = session.get(A.class,5);
select count(*) from A; // scalar query, return value = 10
select id from A; // projection query, returns 10 objects
select A.* from A; // entity query, would return only 9 entity objects of type A, because instance aa is in deleted state
Such discordance would surely create further embarrassments