I've Seen This Partition a Thousand Times
The calculator assumes that the cluster has 1000 partitions.
Why Does This Matter?
Storage
It matters most directly to the local storage requirements. While we can have a set local retention of e.g 15 minutes, Kafka will only ever delete the segment once the segment size is reached. This matters in storage capacity estimation purposes.
Imagine you have a cluster with 100 MiB/s, 1000 partitions, 60 minutes of local retention and a default segment size of 1 GiB. Each partition is only getting 0.1 MiB/s, so after 60 minutes it'll have just 360/1024 MiB of the segment filled.
A naive estimation would think that the cluster would only need 360 MiB * 1000 partitions of disk capacity (since that's the 60 minute equivalent) - but the truth is you'd need 1024 MiB * 1000 partitions of size because that's closer to the maximum size of disk usage the cluster will see before the brokers begin deleting data.
It's precisely for that reason that the number of partitions matter a fair amount in our estimate. Note we only care about "active" partitions in this case. If there are 10k other partitions that are unused (or see trivial KiB/s throughput) - then they don't matter with relation to storage.
Other
Partitions equal replication overhead.
Every broker has to connect to other brokers to replicate. By default, this can result in a lot of extra connections just from replication itself (N * (N-1)) but the connections aren't the issue - the requests over them is. Each replication (Fetch) request sends a list of partition replicas that the leader/follower need to iterate over. At large scale, this can have an impact.
Note that the connection thing (among others) is also a reason why we cap the cluster size.
Partitions equal consensus overhead.
This was particularly the case with ZooKeeper. Now that it's fading away, it's less of a concern. But the gist of it was that loading all those partitions from ZK would be super slow and the controller would have issues with it.
If that's not proof enough, remember that Confluent once reduced a 50k partition cluster's startup time from 6.5 minutes to 3 seconds by fixing a simple debug log. (LOL)