I found the metaprogramming facilities in Boo and Ruby to be quite useful for building domain specific languages. Ayende Rahien's Domain Specific Languages in Boo was helpful when I was building a DSL for test automation. It may not directly apply to JetBrain's system, but it should be helpful for understanding the potential of a flexible language infrastructure.
Java itself has a fair amount of boilerplate that's required in order to get anything useful done. DSLs and code generation tools can help isolate some of that cruft, if they are well-designed. I don't know Jetbrains tool well enough to tell you if it's worth learning, but understanding how to build DSLs and understanding metaprogramming in general is totally worth it. It looks like JetBrains' product occupies a niche similar to the Microsoft Visualization and Modeling SDK, but I found the Microsoft tool a bit too frustrating in my limited use of it, mostly due to the emphasis on visual tools. Since the MPS seems to do a pretty good job on focusing on the text editing experience for the generated DSL, that might be enough to convince me to dig into it.
There's a certain subculture of developers who are cynical about any kind of meta-programming, and another subculture that is skeptical of any language X where X is not the language they are used to. Sufficiently old-school programmers may recall the 4GL movement that turned out, like many over-hyped endeavors, not to be all the vendors promised; some vendors claimed their language would let businesspeople who understand their domain write code and minimize the need for lower-level programmers. That rarely worked out.
So you may have some organizational resistance to using such tools, but like any tool, used effectively, it can make your team more effective and efficient.
The downside is that, unless you're already experienced doing so, building a DSL may still take you more time than building similar business logic the way you always have: in the clunky constructs of your usual language. The payoff, over time, is worth it, in my opinion. If you've worked with a system that uses metaprogramming effectively, like Rails in Ruby, you'll quickly understand how DSLs can pay off. If you've used something like Boo to build a DSL by altering the compiler pipeline (less painful than it sounds, at least in Boo), you quickly enjoy the power better ways of expressing your problems.
But unless you've got a team that is already in their element using such tools, you'll need to start slowly. Maybe the business rules for pricing a contract or product would benefit from a terse, easy-to-read language that allowed you to rapidly respond to changes in offerings, discounting schemes, etc. Or you could find the most tedious, repetitive coding task you have and explore whether a DSL that simplifies that task can help you.