The most significant reason that it is not practical to simulate varying demand patterns is because the routing of passengers and goods is an extremely computationally intensive process, especially on larger maps. In order to get adequate performance, a single route to and from every possible destination and origin is calculated (and periodically recalculated) and stored. The system for doing this was written some time ago by a particularly talented programmer (Knightly) who sadly no longer works on Simutrans. If passenger demand varied, then there would also have to be a varying timetable to keep up with demand: but that would mean that there could not be a single stored route from each origin and destination, as the routes would change dynamically throughout the day. That would vastly increase the computational load. I cannot think of any means of satisfactorily accounting for this variation within a system that calculates routes based on journey time, stores them, and refreshes them periodically.
It is conceivable, I suppose, that somebody with the skill of Knightly could come along and produce an efficient system that works with varying demand and a set timetable. I have no idea whether this is possible: certainly, nobody is volunteering to do this at present, and I do not have the ability to do that. However, even if this was done, it would need people to create full timetables for their services. Creating a timetable for any non-trivial network (with properly timed connexions, and designed so as to optimise way and vehicle usage) is a very significant task: so significant, in fact, that doing it for real life transport companies is a serious and very lengthy job. This level of micromanagement in a game such as Simutrans would make playing it more like hard work and less like fun, and would take away the basic joy of playing a game such as this. Again, it is conceivable that some extremely talented programmer might invent some automation mechanism for timetables that makes them as easy to implement as the current system, but that would mean that Simutrans would be working on the same level as professional transport timetabling software that is sold to real transport companies for many thousands of pounds, so it seems to me highly unlikely that (1) anybody would in fact devote that level of time and skill to creating something so vastly complicated for Simutrans; and (2) that something that complicated could be made to work at satisfactory speed on present day computers.
To answer your further questions:
(6) at present, the level of obsolescence varies only with time. There are plans (see
here for more information) to increase the sophistication of this model such that maintenance costs of vehicles increases with the number of kilometres travelled and is reduced by periodic overhauls (which would be automatic and largely transparent, to avoid the need for tedious micromanagement); and
(7) the cost of all the various things necessary to run and maintain vehicles, ways, etc., is abstracted by the maintenance costs. One of my long list of coding projects is to allow these costs to vary over time to simulate, e.g., the increase in labour costs over time: see
here. As to strikes and career promotions, it is not practical to simulate that sort of detail in a game of this sort.
As to private cars, the main factor in determining whether passengers use a private car or public transport is how congested that their origin and destination cities are, although the relative speed of the two journeys, as well as how overcrowded that the origin stations are are also factors, as is the length of the journey: for very long journeys, passengers start to prefer public transport. Congestion in each city can be observed on the city graphs window.
