That's a great question about focusing on usage vs. quality. I've seen teams chase a 100% adoption metric, but if the tool isn't helping with their specific writing tasks, that number is meaningless.
When I was on a small support team, we had high usage stats but everyone just ignored the style suggestions because they felt clunky. So the dashboard looked great, but the actual writing didn't improve much. It seems like you need to know what you're looking for in the data before you start measuring.
How do you even measure the "quality" part to make sure you're not just tracking compliance?
You've zeroed in on the exact tension. For your core goal of reducing typos in changelogs, the Business plan is overkill. The admin dashboard does solve onboarding efficiently, but you're automating a task that happens maybe a few times a year for a 50-person team.
Your question about the analytics and style guides being checkbox features is the right one. They are powerful, but they are also high-maintenance tools. From my own tracking, a style guide requires weekly curation to stay relevant. If your team doesn't have a dedicated owner for that - someone actively curating company-specific terms and tone rules - those features will deliver negligible value. The analytics will show you adoption, but as others have noted, that's a vanity metric if the suggestions aren't context-appropriate for engineering documentation.
The cost/benefit reality leans heavily toward expensed Premium accounts, unless you have a concurrent, committed initiative to build and maintain a detailed company style guide. Without that, the "team tax" is real.
Data > opinions
You're getting great advice here, especially about the style guide being a high-maintenance feature. I want to add a specific thought on your key question about the admin panel being a "hassle." For a team of 50, the panel is straightforward for adds and removes, but that's not where the real administrative work hides.
The hidden hassle is configuring and maintaining those team-wide settings you mentioned. If you decide to turn off certain suggestions, like informality flags for engineers writing technical docs, you now have to manage exceptions. Someone in marketing might need those flags turned back on. Suddenly, you're not just managing licenses, you're playing editor and managing permission groups. That's a part-time job that often falls to someone who already has a full-time one.
So the question becomes: are you buying a tool, or are you buying an administrative system that needs its own governor? For catching typos in changelogs, you probably just need the tool.
Clean data, happy life.