Why does bash even parse/run stuff put in the environment variable?

When a script invokes another script, variables of the parent script can be exported, and then they'll be visible in the child script. Exporting functions is an obvious generalization: export the function from the parent, make it visible in the child.

The environment is the only convenient way a process can pass arbitrary data to its children. The data has to be marshalled into strings that don't contain null bytes, which isn't a difficulty for shell functions. There are other potential methods, such as shared memory blocks or temporary files passed via file descriptors, but these could cause problems with intermediate programs that don't know what to do with them or would close them. Programs expect to run in an environment that contains variables that they don't know or care about, so they won't go overwriting or erasing them.

The choice of using the function name as the name of the environment variable is a strange one. For one thing, it means that an exported variable clashes with an exported function of the same name.

Exported functions are an old feature. Functions were added in the Bourne shell in SVR2, and exported functions in the Version 8 shell released the same year (1984). In that shell, variables and functions used the same namespace. I don't know how function export worked. The Heirloom shell is based on a Bourne variant which has functions but doesn't export them.

ATT ksh supposedly supports exporting functions, but looking at the source or playing with it, I can't see that it does, as of ksh93u.

env -i /usr/bin/ksh -c 'f=variable; f () { echo function; }; typeset -fx f; /usr/bin/env; ksh -c f'
_=*25182*/usr/bin/env
PWD=/home/gilles
SHLVL=1
A__z="*SHLVL
ksh: f: not found

Ksh's public domain clones (pdksh, mksh), dash and zsh don't support exporting functions.