I'm carving a few minutes from my vacation time to type this, so there might be more details later on (and answers to other posts as well).
As @Peter-Ostry said, there will always be a fundamental difference in how pressure builds up in the Sylphyo compared to other closed-ended wind controllers, and this might translate into a slight amount of latency in the attacks. As for how it impacts perception, it looks like it's a very personal appreciation. Some don't like it, but it seems more due to how they prefer the tradeoff offered by the other solutions. Some prefer it that way and even say it's allowed them to feel less latency. For instance, one of our artists, Florian Becquigny, quit using his EWI for very nervous pieces because he much prefers how responsive the Sylphyo is in terms of latency. He doesn't seem to care much about the sensitivity aspect of it, so he always plays at very high pressure and completely plugs the bottom hole.
As for the comparison to a Lyricon setup, the latter should offer objectively lower latency (especially on an all-analog system), but again I'm not sure the perceived difference is that important for everyone.
Here's a brief overview of the pipeline involved in turning your breath into sound on a Sylphyo playing its internal synth over headphones.
First, the Sylphyo gathers samples from the breath sensor at 15 kHz, which it then turns into a filtered 1 kHz signal. Keys and other sensors have a lower rate, especially the keys as it often includes the configurable delays that are there to make the thing playable for a human being (but Florian Becquigny, for example, disables all of them because he needs to play pieces at extreme speeds, much than the EWI allows him, and he has done the practice to be able to play like this).
But let's focus on the breath for now. As soon as a breath sample is available, it is sent to the internal synthcard in a "state packet" that takes a bit more than half a millisecond to travel. Once received, it is made available for the internal synth engine, which operates with a fixed 1ms buffer and transmits 48 kHz audio to its codec.
You should add some time to account for CPU interrupts, context switching, and other high-priority concurrent processes, but it shouldn't add much to the overall latency as individually these things are counted in nanoseconds or microseconds.
The path to the Link receiver is obviously a bit more complex due to the fact the data must go to the radio package, over the air, then from the Link's radio package to its main board, and finally to the Link's internal synth, thus latency increases a bit.
Overall, the pipeline was pretty much designed for low latency, and we had to make significant departures from off-the-shelf peripheral driver designs to get there, so I'm not sure even an Arduino-based controller with CV output would fare better.
(I'm not sure my colleagues would be OK with the amount of info disclosed here, so I might redact some parts of this in the future)
You should also factor in that perceived latency will also depend on what kind of sound you play; i.e., what's the synth doing. Envelopes, delays, internal debouncing mechanisms in percussive oscillators might well be more impactful in terms of latency compared to the software pipeline I've described above.
And you should also note that digital synthesis will always respond a bit "behind" compared to analog, because in the digital world you have to deal with a finite sampling rate and resolution, aliasing and other unwanted effects whose mitigations always incur a bit of latency (for instance, smoothing a filter's cutoff frequency). This can be solved with more processing power, which leads to more expensive instruments, or with a simpler synth architecture and more limited sounds.
But overall, the difference between a Sylphyo played over headphones and a Lyricon shouldn't amount to much compared to an average human's just-noticeable-difference in latency perception.
I think we're already crossing a qualitative threshold between a square wave played through the MIDI-USB-Computer path and the same square wave played through the internal synth, as "it feels more like it's coming directly out of my head".
I bet the full-analog Lyricon experience is even better and more enjoyable, but I don't expect it to be "a whole another step" better for a majority of people.
To me, it depends on individual perceptual experience much more than everything else.
The same story seems to repeat in various different fields. When I was doing research on the accuracy limits of the perceptual-motor system, prior to Aodyo, we found that it was pretty much impossible to come up with a formula that would work for everyone. Even without prior training, we had people who could easily do and perceive the equivalent of surgeon work using a high-resolution mouse, while others weren't able to fully utilize the resolution of a basic 2000's-era office mouse.
Peter's suggestion to look into your acoustic instruments is a good one. Sure, once the air is moving, reaction is pretty much instant and action-perception coupling is ideal, but there are a few things that incur latency even in an acoustic context, such as the time to build up air pressure, the key mechanisms if they exist, etc. And we don't necessarily perceive them, or at least we can adapt to them.
More than a decade ago, I worked on a video-based computer music system where latency varied greatly due to the fact the input device was a noisy webcam. In this case, the solution was to add latency so as to arrive at some outrageous number, but it was much easier to perform with it, because latency was predictable and always the same and the body knows how to adapt and anticipate. That human process of anticipation is even the modeling basis of the best score-following systems (used to accompany the varying tempo and expression of a live musician with a predetermined score).
Digressions apart, we could progress towards lower latency by shuffling the software around and maybe making different tradeoffs. I'm not sure if there have been big regressions since the earlier firmware versions, but if there are then we would have an easy first step: correct them :).
