How do you know that
fileTreeorfileshave drawbacks?
Well, I’m a seasoned Gradle expert using it for many years already since its pre-1.0 phase.
So I simply have enough experience to know they have significant drawbacks.
You for example miss them in build scans.
And they are also not shown in reporting tasks like dependencies and dependencyInsight.
Just don’t use them, but prefer a flatDir repository if you really really need local file dependencies.
Most documentation online suggests to use these methods, so I don’t understand what you mean by drawbacks.
By “documentation” you probably mean random blogs, StackOverflow answers, and similar.
Those are often providing bad advice, or outdated information.
Also something that might have been idiomatic in the past could be discouraged bad practice today.
…
You probably came here to get some expert’s advice, so you got mine. 
I tried your method, per this documentation, and it didn’t work, same result:
Yeah, it would have been strange if the result would be different than with for example files("libs/mylib.jar"). But at this point the shared information so far is not enough for me to make any educated guess. But as you luckily provided an MCVE now, the problem is clear. You try to find the lib in example-kotlin-app/app/libs while you put it to example-kotlin-app/libs. You can also see that from the error message clearly, which says it cannot resolve the dependency and the path it looked for, another advantage. After fixing "libs" to "../libs" or moving the files to the expected place, it compiles just fine.
I cannot avoid local dependencies.
Yes, you can.
I have thousands of lines of code that I reuse across dozens of projects (and more on the way). I’m not about to copy that code to every single project,
I never suggested this.
I just said that it is a pretty bad and cumbersome idea to manually build jars and copying them around,
suggesting a much better alternative that is exactly designed for that use-case.
I’m pretty sure Java libraries exist specifically to avoid having to do that. I feel like I’m not asking for anything complicated here, just to create a Java library and then use it locally in another project. This particular example is contrived to figure out how to achieve that goal.
Yes, you are not asking for something complicated and it works just fine if you don’t confuse paths, it is just a bad idea to do it like that.
You could for example instead publish to a local directory-based Maven repository (but better not mavenLocal() as that has a whole lot of other problems) and then use that repository in your other builds.
Or as I already suggested above, you could use composite builds if it is mainly to develop the lib and its usage in parallel as then Gradle just builds the lib before building the app fully automatically if necessary without the need to build jars and copy them around and without loosing dependency information, and you can also edit the code of both in the same IDE right away.