Several reasons:
- Reusability: you can’t reuse scriptlets.
- Replaceability: you can’t make scriptlets abstract.
- OO-ability: you can’t make use of inheritance/composition.
- Debuggability: if scriptlet throws an exception halfway, all you get is a blank page.
- Testability: scriptlets are not unit-testable.
- Maintainability: per saldo more time is needed to maintain mingled/cluttered code logic.
There are more, but it boils down that scriptlets are a bad practice.
You can do fairly a lot at the presentation layer with JSTL and EL. If you comes to a point that it is not possible with either of them and you’re forced to grab scriptlets, then the code logic ultimately belongs in a real Java class. You can use a Servlet
class to control/preprocess/postprocess requests, you can use a Filter
class to filter requests, you can use a DAO
class to do the database interaction, you can use a Javabean
class to store/transfer/access data, you can use a Domain
class for business logic, you can use an Utility
class for static tools.