The number one advantage of using either been or asyncsteem instead of the official python library, no doubt is error handling. I would argue that for a new project choosing one of the alternatives is a no brainer and the question shouldn't be if you should use an alternative library, but what alternative library you should use.

The two main choices I believe are beem, a library with a close to complete python API that allows you to do all that the official lib does but without most of its issues, and asyncsteem, a library that doesn't implement signed operations, but that does implement its functionality in an asynchronous non blocking way, so it can be used with the Python Twisted framework, allowing for scalable networking implementation that don't require the old threadded can of worms approach, but use the non blocking asynchronous setup popularized in recent years by Node JS in the JavaScript world and different asio libs such as boost-asio in other languages .

So basically:

• If you have a huge legacy code base, maybe keep using the legacy official library.
• If you start from zero and need signed operations, use beem.
• If you start from zero and need asynchronous non blocking operations, use asyncsteem.
• If you need both signing and async, currently, don't use Python

I think for this usecase, using an asynchronous approach would have its merits especially if you want some kind of web interface and don't want to be using a database all the time.

You would want to keep something of an in memory cache, probably, spitting through the history of any account you find to be active that you haven't currently cached yet, so you don't need to do last second history exploration. Then you will want to update the cache on new transactions and timeouts that update delegation . If, for example through web interface, an non-cached account is queried, only non-hits will take long to answer.

You could probably do this with Been as well, but you will either need to use old school shared state concurrency (threads, locks, mutexes), or opt for using a database all the time for a data set that should easily fit in memory. With asyncsteem you could do it without threads, mutexes, locks or databases with just one single always running process . This is of cause assuming you need a web user interface. If these lookups are meant purely within the context of a pure STEEM only bot without any non-steem user interaction, then Beem would do just fine, and as you will want to use signed operations to interact with the world, Beem would actually be the best option.

Hope the above isn't too confusing.