It's not feasible to document performance characteristics. Performance can vary across browsers, browser versions, operating system, operation system version, hardware, graphics driver versions, Construct versions, the project settings (e.g. WebGL vs WebGPU) and the specifics of what your project does. Anything we write may well only be true in certain specific combinations of hardware, software, settings, and project logic, and even then, what we wrote may become incorrect at any time as all those things change over time.
As I described before, perhaps counter-intuitively, having an insanely fast engine makes relative differences seem worse than they really are. I think in many cases you're just seeing that effect. Ironically if Construct was much slower, changes would not seem to have much performance difference, and then you wouldn't have "performance quirks" - but everything would be worse overall. This is also compounded by the fact as I've described it's extremely difficult to come up with fair and accurate benchmarks that are applicable to real-world projects.
I do believe it's true that for 99% of projects, these types of things just don't matter. Even taking your example with 9-patch: perhaps some settings mean it has to swap textures for each patch, versus rendering it all with the same texture. Changing texture may cause more draw operations (and may not, especially with WebGPU multitexturing). But so what? Going from 100 draw operations to 1000 might mean you are going from 0.5% utilisation to 5% utilisation of the overall system capability (which I must note that Construct's measurements won't accurately reflect due to the power management issue I mentioned) and so you still have absolutely loads of headroom left, and so you're wasting your time worrying about it. As I said the framerate is the ultimate measurement. If it still hits 60 FPS, it's fine.