EnochScript - do I really need it?

Last Friday, I spent reviewing slides from this year's JavaOne Conference. Unfortunately I wasn't lucky enough to attend this conference but my colleague was kind enough to bring copies of various presentation slide decks. They were all quite interesting. They ranged how Java and SOA are meant to partner to writing your own scripting language which can be read by Java. Chaur Wu wrote an article on JavaWorld called "Build your own scripting language for Java: An Introduction to JSR 223" which talks about how developers can write their scripting language. This is a neat technology and as a technologist I want to create one but the bigger question to ask is, "Do I really need it?". Now we can create scripting languages where we can write our business logic and functions into the scripting language for a certain domain. My question is where do I need it. I can use a Business Rules Engine (BRE), write the logic in a Java application, in a database with stored procedures, triggers or in a BPEL process. Therefore before I start writing EnochScript, I need to ask the question why and what are benefits and drawbacks of EnochScript. I would also ask myself the question how does it benefit my project, my company or my business needs if I write a script rather than putting it in a Java application, in a database (if the the logic is in the data tier) or in a service orchestration (if the data is in the services and logic involves extracting and aggregating data in the service tier).