Unfortunately, the docs on osm2pgrouting are sparse at best - you will find some use cases and examples in the numerous pgRouting Workshops, with further hints and detailed explanations hidden inside the chapters (e.g. here).
As first aid, you can assume that:
reverse_cost is given as segment length [degrees]
reverse_cost_s is given as traversal time (
priority is hard-coded as good measure, given as
FLOAT to allow for priority ranges (i.e. a
1.00 [incl.] and
2.00 [excl.] refers to all major roads [
tertiary], with the decimal part denoting the actual road type)
However, pgRouting does not evaluate anything by itself; rather, it allows for (and expects) custom SQL strings to be passed into its functions, that in turn will get executed as queries dynamically - and only their results will get evaluated.
The tables that are created by osm2pgrouting are best practice structures only, and aim at providing a plug&play experience - they are in no way required for the suite of functions in pgRouting to work and you can freely customize their structure.