NOTE: All of these answers depend on the OOTB functionality. It is possible to adapt the Data Loader to perform all of these actions by using Java and importing the classes; this isn't an answer that covers that in-depth. There is an OSS version of ADL on GitHub, if you're so inclined.
GUI: Does Dataloader GUI work with SAML?
No, SAML requires browser interaction, which isn't built into the Data Loader.
GUI: Does Dataloader GUI work with Delegated Authentication?
Yes, DA is implemented on the server end, so as long as the user's enabled for DA, their password will be verified by the web service.
GUI: Must Dataloader GUI always prompt the user to type in a username / password to be used by Delegated Auth or can those values be passed as parameters to the executable or stored in a config file to be used when the app is launched (silently - not shown to the user)?
Yes, OOTB parameters are ignored for GUI invocations, at least as far as the documentation is concerned; while you could probably default the username, the password is apparently non-optional.
CLI: Does Dataloader CLI work with SAML?
No, you need browser interaction for SAML, so the same rules apply as the GUI here.
Does Dataloader CLI work with Delegated Authentication?
As for GUI, yes.
Does Dataloader CLI require a config file (process-conf.xml or similar) to be generated on the fly to contain the credentials for the Delegated Auth process or can the parameters be passed dynamically to the executable when the app is launched (silently - not written to disk)?
You can use name=value parameters, so you could supply a username and password via a batch file or script. However, the password must be encrypted, so some extra steps would have to be taken to encrypt the password before attempting this method. Supplying the values by command line is the same as placing the values in the config file, but won't be stored to disk.