For Q1: the reply from 2018 is no longer correct. It is best that you have a number of Value Streams <= number of threads assigned to the Persistence Provider in case of InfluxDB. If you have 1 VS or 10 VS this would result in typically the same performance. You should not have tens or hundreds of VSs in the system. My advice is to just have 10 VSs and go with this number forever.
For Q2: it all depends on your definition of "data". For historical data that originates from property updates, I find it hard to believe that somebody would be able to create fast a better system than the one of the Value Streams. Remember that a ValueStream must have a PersistanceProvider, and you can define multiple PPs each pointing to a different DB. This would in effect allow you to store historical data in different databases. However, with Influx, I would really want to understand the data size and frequency to see if I really need for example 10 different Influx instances for each of the 10 VSs I imagined at point 1. InfluxDB is really optimized on writing data and supports high write speeds and I believe that for most workloads a properly sized InfluxDB instance is enough.
If the data you mention is other type of data (mapping tables, historical alarms etc) you probably will need to use either Streams (optimized for writes), DataTables or maybe even pure SQL tables.
For 3: that question is in reality not tied to ThingWorx, since reading/writing that data results in database writes/reads, which at the end of the day need to be optimized in a manner specific to each database. Depending on the data you need, you will find that the ingestion is typically handled quite well by ThingWorx while reading, which might inquire complex SQL/SQL-like queries needs to be optimized based on the impact on the DB server itself.
Note that whenever I say DB server, this might mean InfluxDB or any other JDBC database out there, including the DB ThingWorx uses for its own needs (PostgreSQL, MSSQL, AzureSQL etc).
Overall you'd need to be more specific to what type of data you're querying or storing in order to make sure you get an efficient advice. ThingWorx has a few mechanisms in this area, that need to be well understood before deciding.
