1 GB RAM is not very much, giving more to a database improves a lot the overall performance. Also network and external storage speed are not that great. But I would agree to say for a single user, it should be ok and at least not produce tons of errors (just large number of files will take some time to sync).
In your case it would be interesting to know, what happens when you start to see more and more errors.
File lock can be handled with Redis, encryption takes some performance and there are some additional bugs. I don’t use it, and at the moment I wouldn’t and rather wait for client-side encryption (or use different client-side solutions).
Not sure about the design, I’m not an DB expert to be able to judge. At least they got the locking stuff to redis which already helped a lot. If you have a bit of RAM and can be a bit generous about the database cache, the performance is not so bad.
No, there shouldn’t be issues with the syncing at all. But it’s not all about syncing, there is also collaboration, that you can share files, have a nice web-interface to do so, that you are very flexible regarding different storage types, … If you only take the pure sync performance, the fact that everything is based on php makes it unlikely that it can outperform sftp or other basic protocols. But worst case it should take a bit longer, there are no excuses for errors.
The fork was focussed on the server-side software and the mobile clients. The desktop clients were just taken from ownCloud and the development stalled a bit. Now with client-side encryption, they start again the client development…
(owncloud has worked on a few nice features like virtual file system and delta-sync which are expected in their next version, hopefully this works and gets backported to nextcloud as well).