Why shouldn't I use __init__.py to separate public from private classes?

Question

I am implementing a benchmark. In a subpackage, I have implemented a workload setup. To make the code easier accessible, I want to split the code into public and private classes.

benchmark/
- __init__.py
- benchmark.py -> Benchmark
- workload/
  - __init__.py
  - loader.py -> WorkloadLoader
  - validation.py -> WorkloadValidation
  - internal_logic1.py -> Internal1
  - internal_logic2.py -> Internal2

I see three options:

1. Prefix the internal classes with an underscore (e.g., _Internal1). This has the disadvantage that it will add even more underscores in the code. (For me, underscore prefixes work better with snake case methods than camel case classes.)
2. Move all internal classes to a new subpackage benchmark.workload.internal. This has the disadvantage, that it creates deeper folder hierarchies.
3. Only import the classes that are public in the __init__.py file of the workload package. In theory, you would need another step to look up code, but in practice IDEs like Intellij will do the work for you.

Of the three options, option 3 is the best choice in my eyes. It has the additional advantage, that it reduces the import paths:

# from
from workload.loader import WorkloadLoader
from workload.validation import WorkloadValidation

# to
from workload import WorkloadLoader, WorkloadValidation

This looks like a clean module boundary. Yet, answers from another SO posts seem to disagree: How do I write good/correct package __init__.py files

Question Why I should not use __init__.py to separate public from private classes?

Example

# workload/__init__.py:
from .loader import WorkloadLoader
from .validation import WorkloadValidation