Instead of imagining applications per processor, I imagine this device could map threads or message handlers to processors. It could work better with a functional language or at least some language that didn't explicitly manage parallelism in code but rather in the runtime. Offload the app writer to just coding algorithm and not thread synchronization.
E.g. imagine each timer wait being a processor spinning; each I/o loop being a processor that blocked/looped on an I/o pin state. With so many processors to schedule, it wouldn't stall application progress to spin or block an individual strand (until you ran out or processors). To make this efficient, they'd want interrupts and semaphore state to be hardware-supported. Instead of polling a memory location, block on a shared register masked where each bit was a condition. So instead of a 'kernel call' it'd be an opcode or small loop. Latency of wakeup then becomes about 1 machine cycle.
I imagine with the right runtime support this could be a useful device for a large I/o server. It could reduce latency of processing each client message to just the execution time. No time burned in kernel calls, process switching, stack copying, interrupt/event latency.