gulp.task('css', function () {
    function callback(ctx) {
        return {
            // Configure parser on per-file-basis.
            parser: ctx.file.extname === '.sss' ? 'sugarss' : false,
            // Plugins can be loaded in either using an {Object} or an {Array}.
            plugins: [
                autoprefixer,
                cssnano
            ]
        };
    }
    return gulp.src('./src/*.css', {
        // Source map support
        sourcemaps: true
    })
        .pipe(postcss(callback))
        // Message repport support
        .pipe(reporter())
        .pipe(gulp.dest('./dest'));
});

In this demo callback function as same as postcss-load-config

Config in postcss.config.js or .postcssrc.js, is not same with gulp-postcss at all.
In my fork, they are the same data structures and APIs

So that users can learn one of them, do not have to pay twice times the cost of learning

I see, this is not about changing the docs, but about changing the api. Can't you achieve the same thing with postcss.config.js, why does it have to be inlined? The idea is to only support postcss-load-config when there are no options passed to gulp-postcss. If the options are passed, then postcss-load-config is not even required.

why does it have to be inlined?

In our company, we use postcss under webpack, gulp-postcss use for run stylelint and stylefmt.
So, config in postcss.config.js are css build logic, style lint and fix are write in gulpfile.js.

If the two use the same syntax, it can reduce the cost of learning for the project members.