Benchmarks are a good idea and we'll certainly post some numbers in the near feature. I've searched for some good standardized data sets and queries/algos for graph databases, but found none, so if somebody here has a pointer, I'll be much appreciated!
We haven't added pagination, sorting and the likes yet, because we thought they are more of a priority for a server-oriented database. And HyperGraphDB has been exclusively used as an embedded database where large portions of the graph are kept in main memory and such things are done by application code. But I agree it's a valid and common use case and we'll try to add those sooner rather than later. In the meantime, if you want write to the discussion forum with more info about your problem and I'll be happy to help.
We are using the C version of BDB (which is also GPL) because this makes potentially accessible from C++ if anyone cares to port the Java code :) The Java version actually started started as prototype that would become the "real" C++ version.
As for the license, HyperGraphDB is LGPL in the sense that a version where the BDB dependency is removed will have no strings attached for commercial use. Architecturally, HyperGraphDB has a low-level storage layer that is isolated by a handful of classes and is currently implemented with BDB. So it is not such a major undertaking to replace it, given a suitable (in terms of license, functionality etc.) replacement.
A classical hypergraph can be easily drawn as a bipartite graph (see http://en.wikipedia.org/wiki/Bipartite_graph). HyperGraphDB goes to an extra dimension (with higher order links) and that's hard to visualise if you want to see connections b/w different abstraction levels. Otherwise, once you get past the slightly unfamiliar concepts, HyperGraphDB would make working with complicated models much simpler.
We haven't added pagination, sorting and the likes yet, because we thought they are more of a priority for a server-oriented database. And HyperGraphDB has been exclusively used as an embedded database where large portions of the graph are kept in main memory and such things are done by application code. But I agree it's a valid and common use case and we'll try to add those sooner rather than later. In the meantime, if you want write to the discussion forum with more info about your problem and I'll be happy to help.