At this point you're effectively just hand-rolling your own ECS - and perhaps being in denial about it by touting the fact that the ECS is half implemented at best - rather than eschewing an ECS outright, IMO. If you want to skip the ECS, embrace the natural typing of the language - then you don't need to build something to query and filter components, and can instead just use the language's built-in constructs:
Entity may eventually become a merge hazard on larger teams, and Entity enumeration without archetype filtering may eventually become a performance hazard if done too frequently and naively, but this kind of approach can work fine for many smaller projects.
The crucial difference between having a vector of components is in access patterns - in ECS you iterate over entities that have a given set of component, using queries, with entities that have vectors of components you're still iterating over entities. For something like a roguelike you're generally just dealing with one entity at a time, so this is a very important distinction.
That said, I don't think just having a vector of components is good design, you can do a lot better than that. I think the most natural thing to do in most roguelikes is to have an "Entity" type that's shared between players and monsters and has things that you'd expect those things to have, along with an inventory and potentially some kinds of tags governing behavior. Type Objects etc fit nicely into that kind of scheme.
>and Entity enumeration without archetype filtering may eventually become a performance hazard if done too frequently and naively,
I'm specifically talking about turn based tile based games, here, so iterating over all entities matching a given set of components is rarely going to be a performance concern. It's far more important to make sure you're efficient when it comes to things like AI routines and pathfinding.
