If you don't want to deal with exceptions then don't use them in your code.

Actually it would make errors in a casual exception, so that I could capture it in a more reliable manner.

$variable = [1, 2, 3];
echo $variable;

// Notice: Array to string conversion.

How I can capture that? (In this case, I could avoid it by checking if the variable is compatible, but it is only an example.)

With the feature, I could do:

try { echo $variable; }
catch(Exception $e) {
    if(strpos($e->getMessage(), "Array to string conversion")) {
        echo "Check option `user_type`, it accept only string.";
    }
}

The described behaviour can already be done.

<?php

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
});

try {
    echo $variable;
} catch (Exception $e) {
    echo "D'oh! " . $e->getMessage();
}

?>

Outputs:

    D'oh! Undefined variable: variable

Alternatively, you could always write sensible code that doesn't raise notices.

Your example can handle that, fine.
But imagine that:

I'm developing a framework, and it have a method that return current URL, but check if it is secure too (I don't know what user will do with that), but, even if not, the execution will works normally (user need check that, or I need to develop a method that check it "manually").

With this option, I can thrown a casual exception, but not fatal. User can check that or just ignore. It'll depends if user really want to capture this exception. Supposing that he is just logging user URL, for instance.

    $log->url = Framework::getCurrentUrl();
    $log->save();

In this case, I not need capture the exception, I just not need to check security on URL.

Now, if user need to avoid bad URLs, I can do that:

    try { $user->url = Framework::getCurrentUrl(); }
    catch(BadURL_Exception $e) { 
        echo "Sorry, your URL is insecure.";
        return false;
    }

To uncaptured exception, PHP can show a notice error, that can be hidden on error_reporting() or INI;

Considering that exceptions are meant to alter program flow, the proposed "causal exception" is not really an exception. It's a camouflaged call to a global function that later returns to the caller. Just as any normal function would.

You can achieve the same effect already with code like that:
------------------------------------------------------------
final class Warnings {
    
    public static function consume($callback = null) {
        if (!self::$consuming) {
            if ($callback == null) {
                $callback = function() {};
            }
            if (is_string($callback)) {
                $callbackString = $callback;
                $callback = function($errno, $errstr) use ($callbackString) {
                    eval($callbackString);
                };
            }
            set_error_handler($callback, E_WARNING);
        }
    }
    
    public static function pass() {
        if (self::$consuming) {
            restore_error_handler();
        }
    }
    
    private static $consuming = false;
}

function doSomething() {
    echo 1 / 0;
}

try {
    Warnings::consume();
    doSomething();
} finally {
    Warnings::pass();
}

try {
    Warnings::consume(function($_1, $errstr) {echo "WARNING: $errstr\n";});
    doSomething();
} finally {
    Warnings::pass();
}

Thank you for your interest in PHP and for submitting a feature request. Please be aware that due to the magnitude of change this request requires, it would be necessary to discuss it on PHP Internals list (internals@lists.php.net) as an RFC. Please read the guide about creating RFCs here:
https://wiki.php.net/rfc/howto
If you haven't had experience with writing RFCs before, it is advised to seek guidance on the Internals list (http://php.net/mailing-lists.php) and/or solicit help from one of the experienced developers. 

Please to not consider this comment as a negative view on the merits of your proposal - every proposal which requires changes of certain magnitude, even the very successful and widely supported ones, must be done through the RFC process. This helps make the process predictable, transparent and accessible to all developers.