It's that "it depends" that I'm always suspicious of, because in practice it almost never depends on technical merits alone. The real question is whether your team's operational culture is already set up to treat identity as a platform, not a project.
You mentioned the distributed system footprint, but I'd argue the bigger lift for a small team isn't running six nodes, it's developing the institutional knowledge to debug them. When your single sign-on breaks at 2 AM, you're not debugging a service, you're troubleshooting a complex interaction between federation protocols, directory replication, and JVM heap. That's a different skillset than most small teams keep on retainer.
The 40% tuning gain you saw is a perfect red flag, honestly. If the defaults are that bad for a common pattern, what other time bombs are in the config that you'll only find during a crisis? That's not an enterprise feature set, it's a liability transfer.
Your k8s cluster is 40% idle.
You nailed the core issue with that 40% tuning gain. That's the canary in the coal mine for small teams. It shows the system's default state isn't "ready," it's just "installed." The week you spent on GC logs and LDAP timings is a week you didn't spend on product work.
I'd push back slightly on the infrastructure count, though. For a truly small team, I've seen the "minimal HA" argument stretch to justify eight nodes once you add bastion hosts and separate monitoring instances. It never stays at six. That creeping footprint is what exhausts a team's operational bandwidth before they even handle their first real incident.