What is valid timing of using current_user_can() and related functions?

During the vanilla WP core load the current user is being set up in $wp-init() which is after theme load and before init hook. This is in line with good practice of functionality getting hooked to init or later.

However it is also common practice to call related functions, such as current_user_can() earlier than that. It is by definition required for plugins that work with earlier stages of load process (my Toolbar Theme Switcher plugin would be an example).

Documentation makes no claims for or against this practice (that I could find).

However some plugins seem to hook into user–related functionality and expect the post–init state at all times.

For example bbPress throws following notice:

// If the current user is being setup before the "init" action has fired,
// strange (and difficult to debug) role/capability issues will occur.
if ( ! did_action( 'after_setup_theme' ) ) {
    _doing_it_wrong( __FUNCTION__, __( 'The current user is being initialized without using $wp->init().', 'bbpress' ), '2.3' );
}

For quick demonstration throw this into core’s definition of current_user_can():

function current_user_can( $capability ) {

    if ( ! did_action('after_setup_theme') ) {
        echo wp_debug_backtrace_summary();
    }

Who is “right” in this situation? Is there a canonical determination about allowed / forbidden usage of user–related functions before init ?

The only prerequisite for current_user_can() is an existing wp_get_current_user(). The latter is defined in pluggable.php, so you can use it after plugins_loaded.

The _doing_it_wrong() call you are citing in your question is wrong for itself. My guess is that you took that from BuddyPress or bbPress. Both are running into a recursion if they don’t wait that long. There are other, better ways to prevent the recursion.

In some cases, like changing the locale, you have to access the current user object earlier, so waiting for after_setup_theme isn’t even an option.