Some issues and questions.

[josemendez]

So, I was thinking that I have tried the Burst backend, but in reality I didn't have it correctly configured (I kind of missed the warning in the solver).
I was missing the Jobs preview package. The Collections preview was there but hidden by the package manager (so it wasn't showing me any preview package).
I compiled a build with ILCPP and Burst and it worked!
But after that I created a build with Oni and ILCPP and it also worked
So I assume that installing the Jobs package did the trick.. don't know if the idea was to have it installed also for the Oni backend?
The other small thing that I changed between yesterday and today, is that I disabled safety checks in the Unity Burst menu.

Burst, Jobs and packages in general aren't really that user friendly, so getting everything set up correctly can take a while. Getting caught up in "version nightmare" is quite common. 

Performance seems to be equal using both backends, the build runs at constant 144 FPS, but is just one cloth and the scene is not that complex.

There's lots of settings than can affect performance heavily: fixed timestep length, substeps, constraint iterations, collisions, and a long etc. Some other pitfalls that will destroy performance are having deep profiling or/and the jobs debugger enabled. Some of these are quite "duh", some others take a bit of experience to identify and adjust properly. Using the profiler is often paramount in detecting what parts are taking most time, then you need to know what to adjust to reduce their runtime impact.

The Burst build seemed to stutter a little at the start the first time, but in subsequent runs both seems to start equally fast.

This would be asynchronous compilation doing its thing. By default, and only when running in-editor, Burst uses async JIT (just in time) code compilation: the game will start with all job code compiled as vanilla unoptimized C#. First time a job is called, Burst will kick a compilation process in the background. The job will run awfully slow until compilation finishes and the optimized, Burst compiled version of the code starts running. Subsequent runs will perform fine right from the start as the code has been already compiled.

For a standalone build, Burst code is precompiled. In editor, you can disable async compilation in the Burst menu and all Burst code will be compiled upon pressing Play (see: http://obi.virtualmethodstudio.com/tutor...kends.html)

Also, keep in mind that Burst uses asynchronous compilation in the editor by default. This means that the first few frames of simulation will be noticeably slower, as Burst is still compiling jobs while the scene runs. You can enable synchronous compilation in the Jobs->Burst menu, this will force Burst to compile all jobs before entering play mode.

I will try playing with the particle radius (i was already using the collider thickness), but it also seems your next update is going to solve most of these problems

Hope so  . I don't really want to over-hype surface collisions. As any technique, it also has its drawbacks (slightly costlier than particle collisions, slightly worse continuous collision detection) but it definitely results in collisions that feel way more robust.

Ok, sounds that at least I should divide my delta time, in the fixed updates, by the number of substeps.

That's it. Though I don't think you'll need to substep Unity physics (so no need to divide your delta time), see below.

Well I don't require (yet) a rigidbody attached to a cloth. But without enabling "Substep Unity physics" I am using "non kinematic to particles" characters and game elements (like balls).
And they react to the cloth (slowing down or been destabilized by the cloth), maybe this is not physically correct, but from a gameplay viewpoint is good enough
Would like to know your opinion about this.

Should be good. "Kinematic for particles" means the object won't receive forces from particles, it will treat them as static colliders. So no Unity substepping required.

Hehe I like more arcade like physics and feelings in my gameplay, more than going the true simulation way.
Think more of Mario like platformers, than Little Big Planet floaty jumps.
I wouldn't be surprised that something like Fall Guys use a gravity of 15 or greater, to be honest

I was just kidding . One note though: a large gravity value will cause a large downwards acceleration, which works against convergence: the solver will have a harder time keeping cloth from stretching under gravity, so things might look stretchier than they would with lower gravity. As long as you're aware of this and know how to counterattack if needed (more distance constraint iterations and/or more substeps) all is well.