Well, [text](href) is just a lousy syntax. Quite apart from how easy it is to forget which way round it is, the way round that it is is syntactically problematic: the parentheses are URL code points <https://url.spec.whatwg.org/#url-code-points>, so URL encoding won’t percent-encode parentheses, so Markdown doesn’t actually support all valid URLs, leading to injection attacks if all you do is regular URL encoding, deliberate or accidental, and deciding where an href ends is troublesome and inconsistent, with some Markdown implementations terminating at any right parenthesis, and others trying to match parentheses as a heuristic that helps most cases. The other way round, with the href in square brackets, would have been better in this regard, as square brackets aren’t URL code points, and thus will be percent-encoded. But better still would have been to lean on angle brackets more, matching long-held custom and the other style of links Markdown already uses (just plain <href>). In my own lightweight markup language that I’ve been working on for a while and am now polishing up and implementing properly, I’m currently using [text <href>]. [text]<href> is also quite tempting, with slightly different trade-offs.
(When I speak of the details of URL encoding and which characters get percent-encoded, these things weren’t quite so clearly-defined back in 2004 as they are now, but I believe it was all still true.)
HN doesn’t use Markdown in any way, shape or form, so of course it doesn’t do anything special with it. But anything that does actual Markdown will handle it.