"Can't be run against a real server" sounds like a straw man you just made up? I'm astonished about how much you believe you can ascertain based on this... It's a demo, mocking a server is completely fine and also allow them to show it working without relying on other things.
I mean, this is actually even better. You can expand the mock-server down below and see what's happening.
Would you buy a car if when you took it for a test drive, it had no engine but instead the salesman sat next to you and made "vrrm vrrm" noises for 20 minutes?
Using the library is an investment of time, and time is worth money, so yes.
Reducing server load makes sense. Use a CDN or proxy, and aggressively cache responses.
Adding an entirely faked backend response, so that the examples don't actually show the real traffic it would generate is both adding complexity to the demo, and potentially giving a misleading picture of how usable the library is: for all we know, it's too slow to use as the examples show, because a real HTTP request to a backend is going to be slower than a javascript function returning a pre-determined string.
If instead the salesman took you and a car that included an engine out on a test track, would you not buy the car because the test track was fake? You are not buying the test track so you shouldnt care. You are not buying htmx's demo backend either so you shouldnt care.
In your analogy the 'test track' is still close enough to a real road - just as a functional backend providing fake data is real enough to test the functionality.
I'm immediately turned off by the demo though, because it's relying on a 'fake http server' in the client side JS.
If your toy examples can't be run against a real server, I have zero expectation of it working well for non-trivial examples.