At least for hash functions, the capacity of the sponge is usually twice the security level to properly account for collisions of the internal state. This is why Keccak uses this approach, for example. Gimli-Hash (which has been found to be insecure) also uses a 384-bit state with a 256-bit capacity.
As a result, a 256-bit security level in this situation requires a 512-bit capacity, and then additional space in the sponge for the rate. To get good performance, we want the rate to be as large as possible, and having a large sponge typically requires more computation to mix it thoroughly and provide appropriate security guarantees.
The goal of the LWC competition is to provide secure algorithms for very small devices (such as Internet of Things devices) that cannot handle better algorithms. Considering that the chips in credit cards and transit cards often implement regular algorithms like AES, this means that we're discussing very small devices indeed, many of which may have extremely limited processing capabilities (such as an 8-bit processor with a few kilobytes of RAM). These devices typically will not be capable of supporting the computational capacity required to efficiently implement a large sponge that would be needed for a 256-bit security level, and as such this is not a major target for the LWC competition.
The kinds of devices imagined for the LWC competition are things like RFID tags, lightbulbs, and other embedded devices in relatively close proximity, and the goal is to secure connections so that unauthorized parties can't read or tamper with messages. (You will probably not be pleased if your next-door neighbour can remotely turn on and off all the colour-changing lightbulbs in your house, for example.) Given these constraints and the fact that some level of proximity is usually required, 128-bit security is completely adequate given that the alternative is usually no security at all.
