Update screwing with encrypted disk or keep using windows boot?
UPDATED ANSWER:

I noticed safe boot (hold shift) WAS working fine with CPU available but limited by the fact it doesnt load everything.

I then did Justin Silvers method of removing older kexts. 
Particularly previous to that i was only managing kexts under /Library and ~/Library but now i was also removing older ones from /System/Library.

One of the kexts i removed was PACEsupport and i also moved other Mbox2 related old kexts. These were from pre 2015.

But this didnt fix things immediately and not even after restart, but it did force the cache to rebuild itself from scratch as i watch it do so in verbose boot mode (cmd+v).

So i went out to buy a replacement cord as i had given up on fixing the O.S and was going to try to get my old external HD to restore an old snapshot if possible, then suddenly out of the blue it released CPU resources again &amp; now kernel is processing fine again &amp; now i just need to find the correct way to recognise my old external HD. 

At the time it released resources it seemed to be processing a lot of QuickLookSatellite processes &amp; i took a snapshot here.
As you can see the kernel was using all the CPU (at times up to 1300% or more) and here it falls off the cliff back to 18% seemingly randomly but i think it just finally processed all the kext cache again and maybe some of the removed kexts were no longer preventing it. But i think there were several kexts that were problematic here particularly originally the Commander uninstall kext process was DDoSing the kernel CPU.





UPDATE:

indeed the problem returned. 
however i was able to fix it by doing the below.

After the disk decryption process finished, i still couldn't reinstall the O.S through recovery boot, because of connection to apple server problems, even after fixing datetime synchronisation problems. 

I was however able to get my system functioning again by removing some startup items and daemons that i think were flooding my system CPU usage. I found these via inspecting the console (in utility folder) and by using EtreCheck tool.

Effectively a couple of older kexts were continually polling my O.S kernel (particularly one called Commander, associated with an old WIFI dongle uninstall process and another one associate with an old program called NoSleep that would prevent the O.S from sleeping but was designed for an older O.S). 

These mustve been in conflict with kernel changes in high sierra + update. So they were effectively DDOSing my O.S and consequently kernel CPU was flooded. Stopping these and removing a bunch of unneeded kexts seems to have fixed the problem into a functional O.S again. Im unsure if it was only those two kexts or other removed kexts that ultimately fixed the problem, but at least this gives you an idea of what to do if you have the same problem.

Resources:

osxdaily.com/2011/-3/08/remove-an-agent-from-launchd

etrecheck.com

Result:
My bootup time became faster but seemingly not yet back to pre-problem speed.
However, the O.S is now completely functional again, with idle CPU kernal usage down to minimal and user CPU usage available again.



Originally accepted answer: 


  strangely enough, i used my windows boot for a few days, and even did
  a windows update, then i tried to boot Mac again and its working
  mostly fine now, it still took a bit slower to boot (but not 20
  minutes like it was doing before), and the decrypting is not even
  finished now. So apart from not using the volume for a few days, i
  have no idea why it is now working seemingly well again. Id suggest if
  you have a similar problem to look at the links i've posted in the
  question details. Perhaps just accessing the boot sector with Windows
  helped fix up some files or perhaps it was the last First Aid i was
  manage to do which didnt immediately fix it but mayve fixed it but
  took a few boots for me to realise. its also possible the problem is
  not fully fixed and will return but im offering this as the answer for
  now.