I noticed a while back that the default implementation of the EntryPage uses a core-defined colour for the “entry heading” bars, but I've not commented on it until now because I've been too busy to actively persue the subject. Now that I'm done with uni for the summer, I have plenty of time to debate this!
I think it is a bad idea to have any colours at all in the core layer. The most obvious reason against this is that, when an EntryPage is produced entirely with the core layer (so that the entire page is from core code) the entry bars are the only part of the page with a colour specification, which sets the background colour. The text inherits from the page text colour, which isn't specified and thus falls back on user settings. Consequently, users with a white-on-black colour scheme will be seeing white on that odd blueish colour on core-only comment views.
In addition, it is against the principle of the core layer for it to have colours at all. While it is quite easy to work around having this colour set in core when writing a layout, it adds inconsistancy to the system since until now colours have been the domain of the layout, with the layout free to define and use colours in any way that is appropriate, with an appropriate descriptive label specific to that layout.
What are the benefits to having this colour in core? Sure, it means that the default EntryPage implementation looks quite a bit like the old talkread page, but this is hardly a major win as layouts are going to redefine it anyway. I can see that it might be considered nice to have some easy visual feedback to show where comments start, but perhaps we could do that with CSS-added borders instead, which can thus inherit the text colour of the container?
As layouts get comment support, this default core implementation will become essentially invisible, so having a colour from it showing through into layoutspace seems slightly weird.