Pretty much bang on, you've enough technical chops to distill the jargon 
1. Yes. If a standalone script, you would have to maintain a separate list of IDs/names/expiries. (Inadvisable and extra work alongside a management app, but if one only has DIY offline management processes not so much an issue.)
2. Yes. You can use an input/trigger such as an RFID swipe to do anything you want -- the output/action, in your case unlock a door (and maybe checkin). If we got fancier still you could turn the lights on, start a coffee brewing etc
I like and do agree with what Sayles says on the human interaction element however not all spaces have a full-time manager, nor necessarily at the door, and thus tech-driven solutions are needed.
3. Yep. Darned humans, they can be too polite and don't know how to keep their variables within a system's process bounds. 
I would always advise making allowances for this, whether technically or with backup/primary manager-driven interactions. Anything that introduces potential frustration to a user is obviously a bad thing. I think WiFi as a primary checkin system is better than RFID, but with RFID for access control. WiFi can actually check people in even as their phone approaches the main door.
If you need, and how you implement such tech approaches is also down to size, smaller spaces probably don't need either if they're staffed because you know who's-who and can address them directly about renewals/usage. Large spaces really need both especially if managers are not always present. If you're mid-sized both could be nice and I understand given the apparent complexity why spaces haven't used both, but it's not unduly hard if you've got someone who can help. However no management app has the complexities figured out to result in a simple user experience in all scenarios. This is where the best practices/advice for models and approaches from other's here can be help, such as Sayles' recommendation for direct interaction, assuming they align with one's own resources.
If access control is a priority then you can forget the WiFi. Whereas if you have hourly billing or a usage-based plan then WiFi is really required for accurate billing if the access control is loose ('door holding').
Nexudus' own WiFi checkin involves installing a special router, which for two reasons I don't like: 1. it's not a particularly powerful one (although I haven't checked the latest models but I doubt they're as good as dedicated WiFi/routers which is after all at the crux of a space's service), 2. I despair at any system that requires users to login using a webpage especially when carrying multiple devices, let alone keep a browser window open. For ease of use WiFi should simply be password-protected and that's that.
I implemented for myself an essentially opt-in simple WiFi script as a primary checkin system that only requires a user to signin a single time for at least their primary device. This approach could however be made to require users to signin every new device. Maybe the management app devs will improve their systems in time… otherwise we have to hack together our own solutions using their APIs if we want better WiFi checkin.
4. This is down to the specific implementation of a RFID script/program, personally I'd make it part-and-parcel to sync with a hosted app so that if the net is temporarily down it keeps the last valid membership state for each user to always let them in, and also the last swipe times to sync as checkins with the app.
An "API" (Application Programming Interface) is a set of functions that one application can use to talk to another, e.g. a local script/program to a hosted management app. If the management app has a suitable function you can invoke that function to get/set stuff. The Nexudus API is quite comprehensive, and allows you to manage RFIDs, users, checkins and apparently WiFi devices too so strictly speaking anything you want to do could be integrated, and thus it appears one doesn't in fact have to use the Nexudus WiFi checkin system but use one's own.
Such a script/program has to be always running watching for swipes, and whenever one occurs, attempt to connect to the management app API to validate/checkin the corresponding user. I've used these separate terms to differentiate between the locally-running script/program (on a controller board/PC) and remote hosted management app (on the cloud) but technically they can all be considered as 'apps'.
@Sayles offline sync is what you've already done for your own system? What was the issue with the Pi?
Sarah, there's a pile of such controller boards and they're not all compatible so when having a program written to do this, one has to make sure the hardware device ('board') is appropriate. There are however some that make it super simple and you can download apps from the 'cloud' to it with a click. So imagine if you simply ordered this controller board, plugged it in, had an electrician connect a wire between it and your door lock and another to the RFID reader, then that I said all you have to do is go to a webpage to enable the app/script on it. Obviously said app needs to be written though…
*But* I haven't investigated the security implications of this cloud system and indeed I wouldn't want such a board directly exposed to the net anyway. Your insurers might'nt be too happy, although I'd be quite surprised if they'd have clauses about such things yet…? Otherwise you'd need a local hacker who can write/install the script/program directly on any controller board (e.g. RaspberryPi, BeagleBone, Arduino, …).
HTH.
Seems like setting up for roaming and so on still isn't as easy as with UniFi APs though…