SDL_SetEventFilter is a way to "get ahead" of SDL's event queue. You basically get the events as they are received, before they get placed in the queue, and in iOS case you have to react to them immediately.
The technical reason behind this is that for these sort of messages, iOS uses a series of callbacks, which SDL receives and wraps for you in order to make the cross platform experience as seamless as possible, but the fact remains that iOS still expects you to act on them before returning from the callback.
So, for example, if we were to just put the message that the system is low on memory on the queue instead of passing it directly to the app via this mechanism, and you just do nothing until that event goes through the queue, you poll it, etc, iOS can forcefully close your app because it doesn't behave as expected.
When the app goes to the background, you don't need to save your textures. iOS does it for you, and if it doesn't have enough memory to do so it just kills your app (you don't ever loose the GL ES/ES2 contexts, which is something that can happen on certain Android devices).
The userdata pointer is going to contain the data you pass as the second parameter to SDL_SetEventFilter, so if you use SDL_SetEventFilter(HandleAppEvents, NULL), userdata will be NULL.
On SDL_APP_WILLENTERBACKGROUND, if I remember correctly, you don't have to do anything. I haven't fired up my iOS app in a while, but I think SDL handles all of its internal state (including blocking the event loop and then restarting it) on its own. The events you do have to handle yourself are SDL_APP_LOWMEMORY and SDL_APP_TERMINATING, how you handle that is app specific though (delete textures, free memory, etc, it goes beyond SDL specifically)