I think we could define "layer" so Facade could be one. Or not.
The intent of Facade is to provide a unified and simplified API to a set of, well, less simple objects. My best experience with it was when we had several teams building components in parallel. When I needed a new API from the Contract team they could put a new method on their Facade and make it return some canned value that I could
test with in minutes. Then they could huddle and design a real implementation at their leisure. I never had to see all the little implementation objects they had inside their component.
The intent of Business Delegate is to hide all the complexity of remote calls. They often double up as service locators. If I build an
EJB server I can give clients a POJO delegate that they can call like any other object without knowing a thing about EJB remote calls. I use a vendor product with business delegates with multiple protocol implementations - local calls, remote EJB, proprietary raw socket protocol, XML/HTTP, etc.
Both are focused on making life easier for clients. If you write all the code from end to end that may not seem important. If you publish an API for everyone in the Enterprise to call, ease of ouse may make or break acceptance.
They're just good OO stuff some times, too. I would not be surprised if the "information hiding" value could make either or both worth while in many systems, even if I write the whole thing solo.