Обертывание Exceptions

Тебя интересует "почему" или "зачем"? Если "почему" - то просто потому что можем, потому что класс RuntimeException с конструктором (Exception) это позволяет. Более того, я бы сказал, что он для того и нужен, чтобы оборачивать checked и делать их unchecked. Что тебя конкретно в этом смущает? От того, что ты поймал FileNotFound, файл у тебя от этого не появится, и ошибка в дальнейшем алгоритме никуда не исчезнет. Разница в том, что с этими исключениями происходит дальше. Если ты работаешь с проверяемыми исключениями, то у тебя по сути два варианта - либо обработать его на месте в том же методе и предусмотреть, что делать при возникновении того или иного типа исключений, либо пробрасывать его выше и выше до тех пор, пока не пробросишь до того места, в котором ты хотел бы это исключение обрабатывать. Если же его обернуть в непроверяемое исключение, то ты можешь его просто выбросить в этом месте, и на другом уровне приложения предусмотреть какой-то общий ExceptionHandler, какое-то общее место для обработки всех исключений твоего приложения. То есть проблема с FileNotFound exception состоит не в том, что указанный файл просто был не найден, а в том, что у тебя от этого файла зависела какая-то часть логики приложения, и она не смогла быть выполнена. И тебе в связи с этим нужно что-то сделать, например вывести сообщение пользователю и начать какой-то алгоритм заново. Представь, что у тебя таких мест в программе много, и тебе тогда нужно в каждом месте делать обработку этих исключений. Вместо этого ты можешь написать класс SomeLogicFailedException extends RuntimeException и в нужных тебе местах расставить throw SomeLogicFailedException(caughtException) и написать один хэндлер, который уже будет ловить конкретно этот тип исключений и выполнять соответствующие этому действия.

Что именно ты понимаешь под "обернуть"? если throw new так ты просто бросаешь новое исключение, не более того.

try {
    new FileInputStream("несуществующий_файл.txt");
} catch (FileNotFoundException e) {
    throw new RuntimeException("Произошла ошибка ввода-вывода", e);
}

Учитывая наличие общего родителя Throwable проблемы такое оборачивание не вызовет. Ну или уточни вопрос.

/**
 * The class {@code Exception} and its subclasses are a form of
 * {@code Throwable} that indicates conditions that a reasonable
 * application might want to catch.
 *
 * The class {@code Exception} and any subclasses that are not also
 * subclasses of {@link RuntimeException} are checked
 * exceptions.  Checked exceptions need to be declared in a
 * method or constructor's {@code throws} clause if they can be thrown
 * by the execution of the method or constructor and propagate outside
 * the method or constructor boundary.
 */
public class Exception extends Throwable {

The Throwable class is the superclass of all errors and exceptions in the Java language. Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the Java throw statement.

One reason that a throwable may have a cause is that the class that
throws it is built atop a lower layered abstraction, and an operation on
the upper layer fails due to a failure in the lower layer.  It would be bad
design to let the throwable thrown by the lower layer propagate outward, as
it is generally unrelated to the abstraction provided by the upper layer.
Further, doing so would tie the API of the upper layer to the details of
its implementation, assuming the lower layer's exception was a checked
exception.  Throwing a "wrapped exception" (i.e., an exception containing a
cause) allows the upper layer to communicate the details of the failure to
its caller without incurring either of these shortcomings.  It preserves
the flexibility to change the implementation of the upper layer without
changing its API (in particular, the set of exceptions thrown by its
methods).