Answer By posing this question, you seem to be comparing RMI and EJB as if they were the same type of technology and they are definately not. RMI is a lower level technology that allows java objects to be distributed across multiple JVMs. Essentially, RMI abstracts sockets and inter-JVM communications.
EJB, on the other hand, is a technology built atop of RMI but does so much more than allow java objects to be distributed. It is a framework that allows you to build enterprise applications by (among other things) abstracting transactions, database access and concurent processing.
Having said this, the answer to your question is the following. The home interface is EJB's way of creating an object. Home interfaces act as factories to create session beans and entity beans. These factories are provided by the application container and take care of many low level details. Since RMI is a lower level technology, it does not offer the home interface. You would have to create it yourself.
Ans:2. Although EJB originally started as a technology for remoting, and therefore made use of RMI for containers implementations, the technology has now outgrown its original intent. The introduction of local interfaces geve EJBs a boost for situations where remoting was not necessary, leading to faster intra-VM calls.
In view of this departure form the remoting nature of EJBs, I do believe that the real defining feature of EJBs is the life cycle management provided by the application server. In recent years, the JVM itself has received many improvements in the area of memory management and garbage collection. Sun and IBM have both studied carefully the usage patterns on the servers and built agressive optimization strategies.
Marc Fleury (the vibrant voice behind JBoss) recently published an interesting white paper about the optimizations built into modern EJB containers, as well as an interesting view (I happen to share it) that with the flexibility introduced by CMP 2.0, EJB containers are rapidly becoming elaborate caches. These caches keep the raw database data in a format directly usable by Java code, taking care of synchronizing memory and database when necessary.