There's some superficial similarities, but they're very different in practice. The most obvious thing to me is the security model (which is non-existent for HTAs). In fact, HTAs are broadly considered a dangerous file type at this point, because they implicitly have full privilege of the user that runs them. By contrast, Chrome applications prompt for any required permissions (defined within an explicit security model) and are confined to their application container. A Chrome app can interact with the OS and external systems only through those allowed permissions and authorized intents.
HTAs also lack many of the aspects of real applications. Many common operations just aren't possible with an HTA (e.g. basic network sockets, USB devices). And HTAs don't support any significant OS integration, such as file associations. In contrast, Chrome apps are intended to be robust enough to support something as ambitious as implementing your own browser, but to do so using a safe, portable framework.
You are correct, of course, but it seems to me that the only reason for thus situation with HTA is that it never took off and MS dumped its further development. Which makes me wonder if these kinds of technologies simply have no future whatsoever, or are yet to be accepted by the mainstream.
With access to the FileSystemObject or automation access to an OCX you could do either of those things. The power of HTAs is you could use anything provided by a Microsoft technology, script Office, access WMI, etc.
I wrote a DVD backup solution using HTAs and FSO.
HTAs also lack many of the aspects of real applications. Many common operations just aren't possible with an HTA (e.g. basic network sockets, USB devices). And HTAs don't support any significant OS integration, such as file associations. In contrast, Chrome apps are intended to be robust enough to support something as ambitious as implementing your own browser, but to do so using a safe, portable framework.