My rule of thumb with random access files is that there the wrong answer, no matter what the question was! On one extreme, the programmer is in database denial, thinking they can get away with a flat file solution, and on the other extreme, they haven't thought about the design enough. Either way, my advice is to lie down until the urge to use RAF passes.
Maybe you should elaborate your "experience", or else people don't understand how you achieved this opinion.
If you have a stand-alone program, and a huge amount of data (hunded of megabytes), it's faster to just store the data in a RAF and care for it yourself than accessing a database and let the database store it for you. Especially if you don't want to install a database or configure it.
This means faster way of storage and less code to write.
Also if you write a database-application, you need RAF, which is used internally in every database.
On the other side, a server can write several megabytes of data in one second, so if your data size is less, it's better to read the whole data in, manipulate it and then write it back.
Then you don't need to care about fixed sizes of your records (you can easily increase/decrease size), no need to care about too many gaps inside the data and reducing them by shifting records around etc. Also if you need to update several hundred records at once, then chasing the hard drive head around is much,much slower than writing the whole file at once. On the other side, if you need to update only one record in a while, then RAF is faster.
Usually it's better to save a huge amount of data in multiple small files than having all data in one file, so a "design change" is better than using RAF.
Just think of data corruption: Losing one small file, containing one record, is better than losing the big file that contains all records.
For example email saved in Thunderbird (all small files) or in Outlook (one big file).