I am hopeful that your question is confused rather than you and or whoever is providing this information to you.
Retrieving data from a database is a relatively expensive operation. Period. Doesn't matter why you do it. That however doesn't mean that you can retrieve it once only. The business needs drive in what way it can be retrieved.
You put database code in a database layer because that has multiple benefits. You don't put database code outside the database layer because doing that completely violates the point of having the database layer in the first place.
And notice that nothing in the above has anything to do with stateful or stateless.
For example, I once put an object reference inside a Hibernate DAO class and I was told that this was incorrect because DAO classes are not supposed to have state. State should be inside the 'service layer'.
As a general statement that is nonsense.
Implementing code for real businesses is not clean. You attempt to create well crafted code but only to the extent that it makes sense to meet the needs of the business.
Other than that I can only suppose that you did something really wrong in terms of service separation and database layer separation and that point was being emphasized.
The database layer should to database stuff. The service layer should do service layer stuff. Again normally, not exclusively.
And note that none of this has anything to to with the general topic of object creation. Nor with performance.
Create it once there and let the rest of the application access its instance later. Do not create this instance upon every call.
As stated generally nonsense.
It depends on what the object does. I don't need to retrieve the database connection string on every call. There is however no point in not creating a StringBuilder on every call.