There are a couple of questions on design solution.
CAPWAP tunnel is created between the controller and the access points. The ends of the tunnel are the controller's "ap-management" interface and management interface of access point. I've discovered that having the AP and Controller in different L2 domains is best practice, but in theory this seems like a better solution. Which is correct?
One of the wireless networks will be the guest WI-FI. A secretary will create access attributes. Is it require to create an additional interface (in corporate network) on the controller and give credentials to "Lobby Admin" to implement such a scheme?
Putting the APs and the controller in the same L2 domain is the simplest solution as you don't have to do anything else for them to find one another. If you put the APs on a different subnet then you have to either configure DHCP option 43 on the APs subnet or put in a DNS entry for cisco-capwap-controller.DOMAIN-APs-GET-FROM.DHC. Formerly this was cisco-lwapp-controller.
You'll need to give the secretary either admin or lobby admin access to the WLC so that they can create the logins. It doesn't need an additional interface for guest wifi but you can use one and plug it into the DMZ for better isolation.
Edit: Corrected DHCP option number as @generalnetworkerror pointed out my faulty memory.
APs and the controller being on the same subnet is rather unlikely. You'd probably have a centralized controller somewhere in your organization and the APs would be plugged into ports in different IDF closets which span multiple subnets. When the APs boot up, they take the domain-name assigned via DHCP and try and resolve CISCO-CAPWAP-CONTROLLER.domainname.com or CISCO-LWAP-CONTROLLER.domainname.com and tunnel back their CAPWAP or LWAP tunnels there.
Having the same L2 VLAN spanned around your multiple switches and trunks is dangerous from a STP pov. So I would say having APs and Controllers on the same L2 domain is bad practice.
This allows the secretary to generate usernames and passwords for guests as well as email them the information (they can read it on their smartphones and login) and specify the length of time in which the account will stay logged in for.
That way no one knows the PSK or generic login using web-authentication.
It is also best practice to event encrypt the open/guest wifi-network with a simple password to provide user security.
You could attempt to keep the APs and the controller's management interface in the same L2 domain but it would not gain you anything but a headache. The architectural is designed to allow you to plug-and-play APs throughout your network even across L3 boundaries. The APs will discover the controllers through a handful of different ways. We use the DNS discovery. (Add an A record for "CISCO-CAPWAP-CONTROLLER.yourdomain.com". I believe there is another A record to add, but it escapes me at the moment)
I'm not sure that I 100% understand this portion of the question. It sounds like a secretary will set the PSK for the guests. In this case I would for sure recommend you have a different interface that does not allow access to RFC 1918 address space. Use an external DNS server. Then all that is left is to give the secretary access into the WLC to change the SSID's PSK.
It is possible to have WLC and APs in the same subnet, but unlikely since it is hard to manage especially in large environments or when you deploy new access points frequently. From my experience: On small locations where you have 10-20 APs and WLC on site it is easier to put them in the same VLAN. On larger installations where you have one (or more redundant) centralized WLC and a lot of APs that are (geographically) scattered, easy-to-configure and 'clean' solution is to use DNS for discovery process. When you have more complex networks, either because of specific requirements or maybe bad design you can use DHCP option 43 (or static configuration).
Using DNS record is a simple solution for discovering the controller especially if you have only one in your domain or you don't care which WLC the AP will join. I like to use DHCP vendor specific options for the discovery process since it is easier then manually configuring the lwapp ap controller ip address but gives more control especially when you can't use different domains for some reason and want to be able to send different WLC IPs to the APs. You can create scope-based policy that have DHCP option 43 with IP address of the controller for the VCIs (Vendor Class Identifiers) of your access points. VCI is sent in option 60 by DHCP client during the initial DHCP discover broadcast and is used to identify the specific class of devices (hence the name). For matched VCIs DHCP will send option 43 with 102 or 241 suoptions that you will configure to hold IP addresses of your controllers (and other clients will not see them).