Einstein@home want damage my PC (VGA cards)?

You shouldn't expect the power requirements to be precisely the same.  It would be normal for different apps on different projects to have different power needs.  Whether the difference you quote is reasonable or not is another matter.  I have no experience crunching Seti GPU tasks so I can't comment.

Part of the story might be to do with how many concurrent tasks run on each GPU device at each project and how many of your CPU cores are running CPU tasks.  You need to supply those sorts of details for anyone to make some sort of guess as to whether or not the power difference is explainable.
 

If the Einstein app uses more power, it will need faster running fans to dissipate the heat.
 

We are analysing data from the large area telescope (LAT) onboard the Fermi satellite.  The data received is broken into blocks (individual data files) which have names like LATeah0040L.dat (the current one).  These data files are distributed to all hosts participating when the first tasks depending on them are distributed.  There is usually a single data file in progress at any one time (apart from 'resend' tasks which might require a previous data file) and this file could be current for days to weeks as there are many tasks (sets of different parameters) to be distributed for each data block.

When tasks for a data file are created, the 'slicing and dicing' is done in such a way that the vast majority of tasks will be of a similar 'size' (equal squares if you like).  But, just like when cutting up a circular pie into a large number of small squares, there will always be a few squares at the edges that aren't full of pie.   Bernd used the term 'short ends'  some years ago when first asked about this.  These seem always to be found in the initial tasks for a brand new data block when first released.  They have less work content so crunch faster.

If you are lucky, you may get a couple when the data block changes but you have to be quick as they don't last for long.  If your host asks for a *lot* of new work at just the right time, you may get a whole bunch of these.  If you check this thread, you will see that others have noticed the same thing.

Taking your first example of a fast running task in your list, its full name is LATeah0040L_36.0_0_-1.5e-11_504_0.  The first parameter after the data block name (highlighted in bold) is a frequency value.  Currently, with tasks for new data blocks, this parameter starts at 4.0 and increments by 8.0 so the sequence is 4.0, 12.0, 20.0, 28.0, 36.0, 44.0, ....  I don't know if it's always this same sequence.  It has been different in the past.  Quite a few of the tasks at these low frequencies seem to be 'short ends'.  They are quickly gone and everything reverts to normal for many days until there is a further change of the data block being used.
 

There's no need to assume that something has changed with the project or that a mistake has been made as this is quite normal.  Short running tasks are no harder on the hardware than standard running tasks.  They pose no additional danger to the health of your GPUs.

This artifact of the way FGRP style tasks are created has been around for many years.  I think where the actual work content is a specific fraction (eg 0.5, 0.33, etc) of the normal content, the credit award is adjusted accordingly.  I don't pay much attention these days but I seem to recall seeing half credit, one third credit, etc., outcomes in the past.

I've just noticed that LATeah0040L.dat has finished and there are now low frequency new tasks for LATeah0041L.dat.  One of my hosts has some and the first one has crunched faster than the high frequency (1204.0) final tasks for the previous data file (I promoted one task to find out :-) ).  Another of these new tasks is estimated to take about one fifth of the usual time whilst the others have the normal estimate.  I expect this one is a recognised 'short end' which will get about one fifth of the normal credit award, just based on the time estimate.