Wayland using Mesa drivers need to either use a DRM render node or perform DRM authentication during their initial negotiation with the compositor.  When the compositor is launched using a DRM lease device the authentication will fail, so render nodes are the only useable option.  

On raspberry pi4, the graphics H/W is divided into two DRM devices, 1 for the display controller (with modeset support, that does not provide a render node) and a second for the GPU (which does provide a render node and no modesetting).  Libweston and mesa do not seem to currently support running wayland clients with a render node when the graphics device is split in this way.

Raspberry Pi 3 has only one DRM device, so should not be affected by this. 
Render nodes are never provided to clients when using the gbm device from libweston, so the same problem should happen on Rpi 3.

Some possible options to address this might be:

1. Modifying DRM Lease to support DRM authentication (possibly by creating a device file in the filesystem that client applications can open and authenticate against)
2. Adding support render nodes on  split graphics devices to libweston and/or mesa
3. If the only DRM calls requiring authentication are PrimeFdToHandle and HandleToPrimeFd, removing the DRM authentication (or allowing in to fail) from the wl_dm wayland protocol, as these ioctls no longer need DRM_AUTH permissions (since Linux 5.6) - i.e. bypassing the need for a render node.