Will using shaders or some other way of talking directly to the GPU always be faster than drawing to the screen in whatever language a game is being (mainly) written in? I guess that code with lots of conditionals is slower on many, (most? all?) GPUs but is that the only heuristic that can be reasonably applied? I understand that there will be edge cases with different hardware and measuring is the only way to know for sure, but I'm trying to figure out whether I should do everything that looks feasible to do in a shader, in a shader, given I don't want to implement it twice to find out which is faster.
In the context of a highly parallelizable section of execution, like drawing pixels to the screen rendered from a some 3D/2D scene, GPUs are almost always likely to be faster because of their architecture. The decision, in a broad sense, for what programs will execute faster on a GPU vs. CPU should be thought of as how many different execution contexts can be run simultaneously without dependency, or basically how parallelizable is the program. In the general case, there definitely are other factors that make the decision more complicated, like branch divergence which you mentioned.
In the specific case of drawing pixels to the screen however, the decision in practice is very simple: GPUs will be faster at, just because it's a ton of tiny operations. You mention other methods of drawing things to the screen within a specific language as a comparison to work done on a GPU or in a shader. More than likely the language will make good use of the GPU when doing these drawing tasks, for example drawing simple shapes, or static images. All of those tasks are likely offloaded to the GPU to be executed quickly in parallel. If instead you mean drawing specific pixels from code executed on the CPU, then certainly you would be better off writing a shader that can execute those tasks in parallel.