Merkle trees instead of the Sponge or the Merkle-Damgård constructions for the design of cryptorgraphic hash functions Most modern cryptographic hash functions use some form of compression function combined with a construction such as the Merkle-Damgård (MD5, SHA1, SHA2, etc), the Sponge construction (with Keccak as a notable example) and variants of these constructions in order to allow messages of indefinite length to be processed.
It also happens that in order to exploit parallelism some hash functions have modes which make use of Merkle trees, such as the tree-hashing mode of BLAKE2 and ParallelHash (not a Merkle tree per-se but still).

To my knowledge there are multiple Merkle tree-like structures that provably reduce the security of the whole construction to the one of the underlying primitive (for example the one described in the Sakura paper and the one described in the Certificate Transparency RFC).

If I am not mistaken MD6 tried to use Merkle trees directly, however I am not aware of any other cryptographic hash function trying such a thing. Is there any reason why more cryptographic hash functions don't use a Merkle tree-like construction directly instead of just adding them as a way to allow parallelism to existing hash functions on top of the Merkle-Damgård or the Sponge construction?
Is there any reason why don't more cryptographic hash functions use a
  Merkle tree-like construction directly instead of just adding them as
  a way to allow parallelism to existing hash functions on top of the
  Merkle-Damgård or the Sponge construction?


The reason is that a Merkle tree comes with computation overheads that the serial hash functions do not have. Such a Merkle tree is less efficient if executed sequentially, compared to the latter. In fact, its memory usage is proportional to the height of the tree (For further information, see this paper which considers constructions on top of hash functions). Furthermore, if you want to use multithreading to provide a parallel implementation of your tree-based hash function on multi-processors/cores, you will have to cope with synchronization costs.

For software applications, it makes sense to favour general-purpose computers. If you are a cryptographer and you want to design a hash function, you will focus at first on security and sequential execution performance, and then on parallelism (as an option). Note that a sequential execution of the mode of operation does not prevent using a SIMD implementation for the iterated primitive.


  To my knowledge there are multiple Merkle tree-like structures that
  provably reduce the security of the whole construction to the one of
  the underlying primitive...


Sakura coding was proposed to allow anyone to construct his own tree-based hash functions, without worrying about security. For this purpose, this coding is assumed to be sufficiently flexible.


  It also happens that in order to exploit parallelism some hash
  functions have modes which make use of Merkle trees, such as the
  tree-hashing mode of BLAKE2 and ParallelHash (not a Merkle tree per-se
  but still).


You are considering that a Merkle tree is a classic binary tree-based hash function with depth in $O(\log n)$. Most people consider a Merkle tree as a synonym of hash tree, i.e. any "tree structure+hash of child nodes".  For instance, ParallelHash and KangarooTwelve that are based on trees of height 2 can be considered as a kind of Merkle tree. They are using trees of height 2 probably for a question of resource usage (and simplicity). If you are interested in parallel hashing with a focus on resource usage trade-offs, see again these propositions.