Telerik OpenAccess ORM is capable of handling large web applications, as this is already been done by other people and even within Telerik - by Sitefinity Online Business Platform, which is entirely based on OpenAccess ORM.
To get to your questions:
1. Splitting the context would make sense only if you will not be using the different contexts simultaneously. If your application will use different parts of the database in isolation for a period of time, and no other parts will be touched, it might be useful since only parts of the metadata would be loaded. Still, it depends on the tables and columns that you would like to have - for 100-200 tables with not too long lists of columns each, splitting won't matter too much, while if the tables are thousands it might make some difference.
Note that if you load all the contexts in parallel anyway, you will have the same metadata in memory, so splitting the context would not bring you value in such scenario. Also, have in mind that data will be loaded lazily by default, so having a larger metadata for a single context class would not mean more data consumption. Furthermore, handling different contexts with different metadata with the current version of OpenAccess ORM would require you to use the AggregateMetadataSource class to manually merge the metadata from the different contexts and the ReplaceMetadata method to start using the merged metadata container. This inconvenience will be resolved with the Q3 2013 release when we are planning to implement a fine-grain control over the metadata management and automated aggregation out of the box.
2. Fetch Strategies are used mostly for performance optimization. For instance, if you have a Person and an Address classes, if you believe you will always need the address of each person, instead of loading it lazily you would load both with one single database call, instead of two separate calls. Therefore I would recommend you to use them selectively, deciding whether they are necessary based on each scenario in your application.
3. If you mean OpenAccess ADO API, it is indeed designed to be used only as a last resort, along with the cases when you need to call stored procedures and functions.
4. In general I would recommend moving functionality to the database only for scenarios, where you are very certain that you won't be changing your back-end from MySQL to something different and in the same time you have very time-sensitive but complex operations in your data access and business logic. One of the best features of OpenAccess ORM is the fact that you can relatively cheaply move from one back-end type to another, which is almost lost as a benefit if you implement your logic in the database.
Could you elaborate more about your idea of using OpenAccess ORM together with ADO.NET - what parts would you implement using plain ADO.NET code? We might be able to recommend you certain OpenAccess ORM features that would help.
In general, I would recommend you to take a look at the several approaches we have defined for handling the OpenAccessContext in web applications, which can be found in this video or this documentation article. Also It might be useful to see why we think OpenAccess ORM is capable of handling complex scenarios, explained in this blog post.
I am looking forward to your feedback or any other questions you might have on OpenAccess ORM usage in web scenarios.
OpenAccess ORM Q2 2013 brings you a more powerful code generation and a unique Bulk Operations support with LINQ syntax. Check out the list of new functionality and improvementsshipped with this release.