Process Hacker will never trigger an anticheat measure in a Steam game using VAC 2. VAC 2 only bans for cheating.
There was one case where having Process Hacker open while playing DotA 2 would get one's account suspended for a month for use of an external tool, but that was reported and fixed.
(Not to be seen as a real argument, but: If they don't see it as a serious threat, why should we?)
Assuming you just confused Process Explorer and Process Monitor.
One advantage of Process Hacker over Process Explorer is, that it is being actively developed. Also, Process Hacker is expandable using plugins, got a feature called "Terminator" which can really help for ending hung processes (or processes trying to prevent itself from being closed), it has some more options for highlighting processes, it lets you search the name of a process on the internet, or send a file to 3 different online virus scanners from the context menu, it provides control over services and notifies you if a service gets created or deleted, it provides a list of all open sockets/connections and is, in my opinion, more pleasant to look at.
Were that enough benefits?
You already have at least two types of countermeasures in place, one of which got quite hard to bypass with the introduction of SD #26. The other one I thought of, VF #...(8 I guess?) (Code integrity checks), is hard to bypass with Process Hacker, too. And probably at least one more preventing modification of game data.
No. One of CheatEngine's main functionalities is searching for values in memory and/or modifying them.
Process Hacker doesn't have the searching part and many other things Cheat Engine does have, because the idea is a different one.
Also, editing memory is mostly prevented through the component that triggers SD #26 if it's stopped.
Again, editing memory, especially memory that is changing is hard to do with Process Hacker. No experiments performed, but I suspect that Process Hacker writes the entire region of memory, not just the things that changed, and that doesn't go very well in rapidly changing memory areas, where after clicking Write, the program will most likely spontaneously crash. Assuming someone managed to bypass SD #26 using Process Hacker (which would be most likely very hard to do), areas watched by the aforementioned VF #something are not easy to edit either, since getting timing right while switching between programs isn't that easy (a bit more so in window mode, but still, someone changing MTA code in-memory has to have a good bit of knowledge in x86 Assembly, and is very likely able to avoid using Process Hacker by either using some less-known alternative or writing a program of their own).
Just another question: Do you know anyone using Process Hacker for cheating in MTA and succeeding?