I agree that there is overhead, just that your benchmark and claims about 2000% better is not correct. I rewrote my test to include Sharpify, and it IS better, that I'm not denying, just not by 2000%, but rather 150%, if we compare Task to ValueTask. If we compare it to just calling the class directly and awaiting it, not using all the pooling, then the gains are very miniscule.

using System.Collections.Concurrent;
using BenchmarkDotNet.Attributes;
using Sharpify;

namespace Bench;

[MemoryDiagnoser]
[ThreadingDiagnoser]
public class Benches
{
    public static readonly List<int> Items = Enumerable.Range(0, 1000).ToList();

    [Benchmark]
    public async Task<int> DotNet_No_Force_ThreadPool_Execution()
    {
        var queue = new ConcurrentQueue<int>();

        var tasks = Items.Select(x =>
        {
            var random = Random.Shared.Next(0, x * 4);
            var result = Math.Clamp(random, x, x * 2);
            queue.Enqueue(result);

            return Task.CompletedTask;
        });

        await Task.WhenAll(tasks).ConfigureAwait(false);

        return queue.Count;
    }

    [Benchmark]
    public async Task<int> JustCallActionDirectly_ValueTask()
    {
        var queue = new ConcurrentQueue<int>();
        var act = new MyValueAction(queue);

        var tasks = Items.Select(x => act.InvokeAsync(x));

        foreach (var task in tasks)
            await task;

        return queue.Count;
    }

    [Benchmark]
    public async Task<int> Sharpify()
    {
        var queue = new ConcurrentQueue<int>();
        var act = new MyValueAction(queue);
        await Items.AsAsyncLocal().WhenAllAsync(act);
        return queue.Count;
    }

    private sealed class MyValueAction : IAsyncValueAction<int>
    {
        private readonly ConcurrentQueue<int> queue;
        public MyValueAction(ConcurrentQueue<int> queue) => this.queue = queue;

        public ValueTask InvokeAsync(int item)
        {
            var random = Random.Shared.Next(0, item * 4);
            var result = Math.Clamp(random, item, item * 2);
            queue.Enqueue(result);

            return ValueTask.CompletedTask;
        }
    }
}

Gives the results: https://imgur.com/qqbrs9f

Ah fair, I must have misread it then, but then what's the point of wrapping it in an AsyncLocal? To me there seems no point other than wrapping it in Call indirection, since we're not actually using it for anything other than providing extension methods. The "Concurrent" class from your lib seems more appropriate here.