As far as I understand all non-faulty members of Stellar network maintain same transaction log (sequence of ledgers in Stellar terminology) and database state. This includes accounts public keys and their balances, and theoretically it should be enough for operation.
Correct
Now there are also some federation servers that provide service for resolving from human-readable name to account ID, and possibly back (similar to how DNS complement IP-based networks, including Internet)
Correct again. Reverse lookups are supported by the spec, but optional.
Are there any additional functions of federation servers?
Domain owners are free to use any federation server, including their own implementations, as long as they meet the protocol spec. This means a federation server can have any side-effect. For example, the server can honour lookups for addresses that haven't been seen before - creating & funding the address in the process of resolving it. Or, navigating a HDNode hierarchy on each subsequent request in order to provide recycled deposit addresses. etc.
Is there any protection against scenario where federation server gets hijacked and starts returning some other account IDs?
This is an attack vector worth considering. There is some protection in that the resolution to federation server is tied to the DNS owner of the domain in the federated address.
Given the address foo*bar.io, the resolution process is to first resolve https://bar.io/.well-known/stellar.toml. That TOML file should contain a federation server URL. In this way the domain owner has control over which federation server is used. But any given domain still resolves to a single server that would need to be hardened.
