I think an important factor is who your service clients are.
If your service layer is just an architectural boundary between layers in your own project, and the service client is within the same trust realm, then it is ok to relax things, and let unchecked exceptions bubble out to the controller layer, or the service client.
However, for public facing code; service that are consumed by a third party or customer, I think it is cleaner to wrap any unchecked exceptions with a service oriented exception, primarily for security concerns, secondly for loose coupling, and clean abstraction.
A data layer exception should never, directly make it all the way to an end user of a web application. It potentially contains internal information about your schema, your queries, line number information, variable or function names, etc. End user exceptions can be sanitized in a secure setting.
An external service client isn't concerned with your implementation detail, and can't handle unchecked exceptions anyway, as they are bug or environmental issues. In secure applications, database errors are simply not secure enough to propagate,
OracleException - ORA-01234 - ... which might be the 3rd table that was inserted. The client should be allowed to deal with any checked/expected exceptions that it can handle, and treat everything else as a potential bug report. Your service contract should be an atomic, consistent, transactional abstraction. If it can't do anything about the exception, then the only useful thing left is to give you a bug report. You already have the ability to log the exception, so why burden your end user with the details? Your app can be monitored, so you already know about the unchecked exceptions before the users report them.
It is never ok to eat exceptions, nor am I a fan of checked exceptions, but I prefer to have a plan that is appropriate for the nature of the overall product.