I'm just wondering...
why is it not possible to declare EJB-QL for a ejbHome() method. Why does it need to go through a ejbSelect() method. I guess this is a design decission but is there a better answer than "this is just the way it is"?
The purpose of ejbHome() methods is to expose the functionality realted to EJBComponent but not related to a particular entity bean and these methods can be called from HomeInterface so their purpose is not to be a type of Finder method , for that purpose we have selectors. So their is clear demarcation between the two type of functions.
ejbHome() methods that wants to perform database access cannot do it directly (e.g. you cannot define EJB-QL in deployment descriptor for a ejbHome() method AFAIK), but you can do this for a ejbSelect() method that acts as proxy for the ejbHome() method. I guess it is a design decission that EJB-QL cannot be specified for ejbHome() methods in the deployment descriptor. I can see the destinction between ejbSelct() and ejbHome() methods but I see no reason for eliminating declaring EJB-QL for ejbHome() methods other than "that is just the way it is".
I can't help drawing a parallel between the relationship between static methods and instance methods in J2SE and home interfaces and EJB objects in J2EE. But the ejbHome() methods are implemented as instance members on the bean (AFAIK they cannot be declared static). This is error-prone. One could for example, access a instance variable in a ejbHome() method, eventhough it does not make sense but programmers do make mistakes. There here is no compile check on it (or is there with some container vendors? not JOnAS). But I should not think of static methods in J2SE being the same as methods in Home inferface in J2EE.
Home methods are simply certain pieces of functionality that are not associated with any specific entity. The parallel of your question for normal business methods would be "why can't I define EJB-QL queries for my business methods?". The answer is not "because that's the way it is", it's "because that doesn't make sense". Home methods and business methods perform general functionality. They don't perform any type of database access by their definition. If they do need to perform database access as a part of their functionality, they can call finder or select methods. The container does not provide implementations for business methods or home methods, so what is that associated EJB-QL supposed to mean anyway? If the container did provide implementation for home methods, running EJB-QL queries, then they would simply be another name for finder methods. The EJB2.0 spec added home methods to address a different need. Finder methods have been there from EJB1.0.
As for your second note, about the fact that ejbHome methods are declared as instance methods: I couldn't agree more. Same goes for finder methods in BMP beans. They strike me as an extremely bizzare choice, and I have yet to see a single good reason for it. As far as I am concerned, all these methods that run with no specific entity identity would have been better off in a different class, a "home implementation class". Like you said, defining them in the bean implementation class only leads to an awkward model where some methods are not allowed to access some parts of the instance, and the destinction is far from being clear.
From everything I could gather, the reasons for this are mostly historical, plus the desire to "keep things simple and avoid adding yet another class" (not very convincing if you ask me).