Ah. I was afraid of that. :\
As far as beats vs. agent, I've had multiple issues with Agent filling up the /opt filesystem, which would then cause issues with the actual apps we were running on those servers. (Side note: I've actually run into issues due to some piece of the ELK stack not checking disk space multiple times. Had to wipe out an FS snapshot repo due to that, and have had Kibana not allow logging in due to disk space before.)
You also used to not be able to upgrade Agent via fleet en-mass without a subscription, though I think that has changed since I was able to do so yesterday. Beats are fairly easy to manage with Ansible, I used to do that before Agent existed, so switching back seemed like a good idea.
I also have mixed feelings about managing configuration via the Fleet UI. It's somewhat handy, but having to configure every single integration for every single variation of a policy is painful. (As in, some servers run apache, some don't, but I have to configure the system integration on both the policy with apache, and any policies without apache. I should be able to just configure the system integration once and then have any policies that need it use the defaults I set.)
With Beats, I'd have everything in Ansible. That makes configuring the same thing on multiple instances easy.
Also, why create a new version of the policy on every tiny change and then deploy that to every agent? Why not wait until I've finished adjusting the entire policy and have said to deploy?
I haven't really looked at Agent's standalone mode. But it's always felt like it isn't how Agent is supposed to be used and I'd run into issues because of that.
So, then there's the way Agent stores it's configuration each host. If you have to debug an integration and want to go into where the actual configuration lives to see it, well, I'm not actually sure you can. Every time I've tried I can never figure out where the configuration actually is for a module/integration. A while back I was trying to debug some issues with the Docker integration and I can't remember if I ever did find the actual config for it...
Anyway, I had moved to Agent because I had hoped we'd be able to actually subscribe down the road and it was obvious Agent was where Elastic was heading. Recent issues here at work mean that isn't going to happen, and even the minimal usage we have on my long term dev stack is eating up more resources than we can afford. So I'm trying to force the Elk Stack to work in ways it isn't designed to. I've been testing using Beats directly to see if that might help with that.
Though, so far, getting the stack to work the way I want has not worked... Everything is built assuming everything is working the "Elastic" way. There isn't much flexibility to change how things work unless you take on massive amounts of configuration. Like what it would take to make TSDS work with Metricbeat. :\
Anyway, some of what I said is probably a bit more negative that it should be. I've just been rather frustrated with some of that for a while and it might have colored my thoughts a bit more that it should.
What I really want is for Elastic to release a stripped down version that is only metrics and logs aggregation. Strip everything else out and make it small enough to run a single node on very few resources. For small dev shops or small community colleges (like where I work), that would be incredibly helpful. That's basically what I've been trying to configure for the past few weeks.
Edit: A more encouraging thing is that the switch to TSDS for metrics is a huge space saver. I hadn't updated my integrations in a while, so just recently did that along with the 8.9.1 upgrade, looking at my indices for a couple metrics data streams shows the TSDS versions using roughly 1/5th of the space as the old ones. So that could help us out a lot! Kudos to Elastic for that.