The main thing is that they aren't related at all.
Forms authentication timeout won't have anything to do with session timeout. Forms authentication timeouts may or may not slide and only store the authentication cookie. Even if they are set to slide a user still has to interact with the server after the halfway point in the timeout for it to slide, else it doesn't.
Session timeout is just there to store data for X amount of time if needed and the timeout will slide.
The application pool is there to keep everything running smoothly. Application pools need to recycle every so often and that can be disruptive, but it's the health of the app and the server they are worried in. Of course, if you aren't using a state server or storing session in database the session can end up killed off as well.
Couple things that help in this scenario:
Use session wisely as it's a pig for resources, and always have a means to check for nulls and recreate the needed objects/values if it is null.
Create a machinekey for your app. This will make sure the way that the app encrypts data doesn't change with each app recycle. If a recycle occurs it could have an effect on logged in users because the encryption of the ticket may not match. A nice side effect of creating an explicit machinekey can also help you use a webgarden if you want, but only if you a state server or store session in db since in memory session can't be shared among processes.
So they aren't inter-related but can effect each other. There is also no way in hell I would want an application to have it's own settings that would over-ride an app pool setting since a well set app pool keeps the site and server healthy and running well and that's the main reason it trumps all.
