I actually think the HUD can easily be made with ECS and even fit with your old way of doing things ...
Not to be offending, but: This kind of thinking has led to the omni-potent scene graph, hasn't it? It is not principally wrong to think so, but only if side-effects and longtime effects are considered, and that is not so easy as the history shows us.
If one uses OOP as the programming paradigm, two principle ways are given: Inheritance and composition (or in practice a mix of those). ECS is in fact object composition made available to the designer. Because composition by itself is so low level, nearly all problems can be solved that way. However, does that mean that all problems are related to ECS?
ECS is a framework made to deal with game objects. At Gas Powered Games, which made the technique popular, the entities were called so, abbreviated as GOs. Text output of a debugger is hardly a game object. The graphics of a game menu belongs to the menu game state, which is in parallel with the gameplay state, of which the ECS is part of; so having the game menu inside the ECS is also strange. Judging the HUD itself is not as easy though, and having a dialog item floating above an avatar shifts things even more towards a game object understanding.
The argument that all those is text, and the wanted achievement of unified text rendering hence requires all examples to end in the ECS because some of them look like components, is the wrong way. Having the game loop being split into sub-systems is a solution independently of using ECS. The graphics sub-system is usually the very last one called in a game loop. Ideally it should not know what the ECS is, because the ECS is a tool to model the world, and graphics rendering just needs a snapshot (in time) slice (spatially) of the world to do its job (keyword: decoupling by queuing rendering jobs). Hence graphics rendering is not interested in which other sub-system(s) sent jobs, only that jobs are waiting to be processed.
What's with the other sub-systems? Input has an impact, for sure. Animation may be used. AI, collision detection, physics, ... usually not. But all these are part of the game loop and work onto ECS. So, when using an ICS ("interface component system" ;) ) it would be wise to clearly separate ECS and ICS, so that belonging sub-systems can be invoked for one set without being disturbed by the other set. For example, something like the Spaces approach may be used (see an introduction by Sean here).
Just my 2 Cents, of course.