Dear Tomáš,
thanks for letting us know, it is important for us to receive this sort of feedback. The issue you report isn't new, we do know that searches can timeout. The first bit of (bad) news is that the behaviour you see isn't due to the Trial version, trial accounts are functionally the same as paid-for accounts, they just start with a default one-month free trial.
Back on the main issue:
First of all, if you are getting timeouts only when using (full-text) searches, but not elsewhere, then this is a known (and somewhat difficult to tackle) problem. If you are frequently getting timeouts elsewhere, then we are dealing with (also) another problem, and I would really like to learn the details.
On the issue with searches: I have good reasons to believe that the problem can be solved, but so far I've been unable to get in the right conditions to actually find a solution. We know for sure that there is plenty of room for improvement (e.g. we can speed up the searching algorithms), however, the subject is tricky because the malfunctioning mechanism is tightly linked to the automatic 'optimisation' routines of the database engine itself. We know that this is the case because the timeouts have the bad habit of disappearing when we start looking: whenever I probe inside the query engine, this triggers more optimisations, searches don't time out anymore, and I'm left with nothing to optimise explicitly.
Hopefully you may experience the same kind of behaviour: it is normal to find that a particular search that was reliably timing out yesterday is working perfectly today (the other way round may also happen, but it's more rare). Also: as full-text searches rely on the creation of full text indexes, and this in turn eventually triggers more internal adjustments, it is also known that recent changes on the overall list of items makes timeouts more likely. If the list hasn't changed in the last 24 hours, the timeouts should be far less common.
The way forward: in order to properly tackle the issue, I can re-design some mid-level logic in ways that nudge the autmatic "optimisations" in the right direction. So far, in other areas, this approach has always worked. However, full-text searches come with some additional complications, so I wouldn't promise that it will be possible to make them work each time without exceptions. On the other hand, in order to do this work, I need to have a long-ish and diverse list of searches that do time out regularly (your examples seem perfect, but I'd need more!). Once I have that (unfortunately all examples I've tried so far "fixed" themselves soon after I've started looking), I would apply the known solutions I mention above. That is to say: I may need your help to identify enough unreliable search queries, without that I don't have a starting point.
Furthermore: we are already moving in new directions with our full-text (and machine learning) facilities, so I do hope that we will eventually implement entirely new "full-text search" facilities, thus side-stepping the issue altogether.
Take-home message is that you can assume the situation will improve, but this might require you to give us a little more feedback in the near future.
Finally: have you looked into the "keyword" highlighting features that can be found in the "document details" window (more details here)? They may provide an alternative strategy to the heavy usage of searches.