Unfortunately I haven't found a meaningful way to get rid of env_climada.yml too.
It seems that getting rid of it would eventually increase complexity.

e.g. a script that translates and exports the content of pyproject.toml to the env_climada.yml file:
it looks like such a script cannot be written properly without adding knowledge of the specific dependencies.

What about this? https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html#dynamic-metadata

We can place the contents of env_climada.yml into a requirements.txt file and have the pyproject.toml reference that file:

[project]
dynamic = ["dependencies"]
# ...
[tool.setuptools.dynamic]
dependencies = {file = "requirements.txt"}

This is still considered a beta feature, but we could give it a try. Of course, the requirements.txt specifications are a bit different from conda environment specs.

requirements.txt files are supported by the conda commands conda create and conda install, therefore a new environment could be created by

conda create -n new_env --file requirements.txt python="3.11.*"

What about this? https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html#dynamic-metadata

After personal discussion, this does not seem feasible. Packages on conda-forge may have different names than on PyPI. The conda environment file also serves a slightly different purpose (creating a conda environment) than the pyproject.toml (check that requirements are met).