They both appear to lock the cookie to a domain, but they are not compatible (in that the use of the __Host prefix necessitates the Domain not being set).
I haven't found a good argument which is the better way to go. I realize that using the Domain attribute has a few features, like allowing subdomains to use the cookie, which seems like the only reason one would use it over __Host.
But all things being equal and assuming that there are no subdomains, can you explain why one would be better than the other?
The __Host- prefix was created to solve a number of security problems associated with cookies and should always be used over the domain attribute. Leaving the domain attribute blank is actually more secure because then your cookie will be sent back only to the same host that set the cookie. This is called the host-only flag in RFC6265:
If the domain attribute is [empty] set the cookie's host-only flag to true.
The __Host- prefix also protects your cookies from being overwritten by web sites hosted on different subdomains of your domain. This is due to the fact that they are also constrained by the host-only flag.
Finally, unencrypted connections leave your web site vulnerable to man-in-the-middle fixation attacks. The __Host- prefix solves this problem by not allowing unencrypted connections to use cookies with this prefix, thus stopping a malicious third party from injecting a set-cookie header with the same name as a secure cookie while users are being redirected from http to https.
If you need to set the domain or path attributes, but still want the security offered by the __Host- prefix, you can use the __Secure- prefix. Like the __Host- prefix, cookies with the __Secure- prefix can only be set from a secure connection.