i think actual dns on ROUTEROS accomplish the role of a local cache for dns queries
if you need to get full dns implementation the only thing you need to do is to put a little and inexpensive linux box as the root of your dns infrastructure, this plus your mikrotiks doing cache can do a very good scalable dns solution
or use opendns or norton dns to custom your dns behavior
i think routeros must focus on polishing wireless routing and networking functionalities to deal with serious competition.
but even as "local cache" its need support of such features, ironically. to do it properly in those tech-aware/depnding environment/solutions.
generally some networkers - avoid NS on routers, simply because security issues and just forward DNS traffic.
(which is important partialy both because broken/outdated/vulnerable/bloated code in some of them or incomplete implementations(especially in security context and "becoming essential" things like IPv6 native support "from top to down")
ironically - that start becomeing common for some security-conscient companies - for Linux and Windows hosts aswell.
(mostly because DNS implementation - remain as insecure as in all router and "caching" feats - seriously simplify exploitation)
also as "local cache" built-in DNS services - lack management options. to easier tweak/manage options, overrides(both for A, PTR, MX resources, TTL(both directions in many styles) and to enable/disable certain things in DNS traffic/configuration itself.
would you miss ability to tune "old-fashioned" DNS traffic in "passive" style(ie 53<->53) for example. in firmwares with open config(either they use bind, dnsmasq, nsd, djb(my favorite aside unbound) or other things code with combinations between) - you can simply edit config and fire it up/restart again.
someone - would probably like something else for DNS aswell, likely. its remain untouched in ROS for really long time.
personally i would like to see improved performance of it(compared to bypassing DNS - difference is staggering, sometimes
so far DNSSec support is sparse/broken, because incomplete implementation and lot of complex workarounds, necessary to make it working in most platforms.
partially cause since TCP Cookie Transactions - removed from kernel again(due same issues/reasons, ie incompletion/buggy status), long ago.
almost just like how SCTP - require both timestamps and ECN support(presently disabled in RouterOS).