Probably the first thing to call out is that solving cross-plat UI in the general case is a non-goal for Adaptive Cards. It's not intended to replace e.g. ReactNative. Adaptive Cards exists to allow small snippets of card-like UI to be defined and shared across platforms.
The problem with using HTML (or a subset thereof) to solve this problem is that it necessarily requires HTML rendering on every platform you want to support.
If your intent as a dev is to integrate card-like experiences into an existing app, requiring a web rendering surface might be too heavyweight... and even if apps chose to adopt web rendering, there would still be the issue of getting styling to line up.
The goal of Adaptive Cards is to use a platform's native rendering and controls. Apps should get native performance with native styling.
Of note, these cards may not be originating from within your team, so there's no way to guarantee that card authors will make design choices that fit within the design language of your app. The solution is to only allow for semantic styling choices (e.g. card author can't specify "Ubuntu Mono" as the font, but can specify "monospace"). The app hosting the card gets to define how these semantic choices are actually implemented.