16 minutes ago, ryt said:

but what made the initial system from start right-handed

It determined by what direction of Z axis we has select to build a system. Let begin from begining. Operation of cross-production build a vector that perpendicular for both of source vectors. But it possible 2 opposite directed vectors that lie on same straight line and have same length.  Wich same of its vectors we selected as positive determine a handness of the system we use.  But for different purposes we may select different directions. Hardware uses RH system. So to make result of calculation in LH system compatible with harware, libraries have a LH set of matrix building functions for base operations, that constracted as mirrorded RH matrices, to perform a conversion to RH system used by hardware by the way. Also any mirror transformation invert handness of coordinate system.

This is mostly just a decision initially taken when a Library is created. Which could also be because the lib is initially used with dx or OpenGL (which have different handedness). In the end there’s no right or wrong; most important is to stick with one throughout everything you do.

1 hour ago, ryt said:

You mentioned fixed part of pipeline, what about non-fixed,

Programmed pipeline part have to convert handness of system that used for calculations, to handness of system used by hardware fixed part for rasterizing. It conversion usually done just by mirrored projection matrix.

1 hour ago, ryt said:

but what made the initial system from start right-handed?

Better say it initially have same handness that graphic API you use. Really you can not see about any differences on calculations until draw a results. Only difference is a rotations direction. By other words if you mean that you perfom a calculations in left-hand system without conversion results to right-hand system you will see on screen mirrored image and opposite rotations for API that use RH system and viseversa for mentioned RH system and API that use LH.  Also inverting handness of system inverts sign of volume integrations. It why CADs usually using LH system instead of much comfortable for visualisation RH system that usually used in CG.  

1 hour ago, ryt said:

is that libraries have a predefined basis vectors pointing in desired direction,

Really it use a - cross only to cunstract matrices where it is significant. It a LookAt and projection matrices only.Just it require to understend from where needs of different handness come. Imagine a front view of any vhechicle for example. How to place axes for it view? Intuitive direction is x "to right" and y "upward", becouse it habitually since  secondary or ever primary school. But how to be with z axe to add a 3D?  It is cross production of x and y but what it direction more comfortable? To find it direction we have to look on side or top view. It intuitively comfortable when it have positive direction to front of vhechicle. On front view it direction "to us". So for model space it is comfortable a left-hand system. But what comfortable for camera space?  x "to right" and y "upward" again most comfortable directions. But how to be with direction of z? On camera z is intuitively distanse to object, so comfortable direction is "away", so it right-hand system . But if we will draw model built in left-hand model space to rigth-hand camera space we will see a back insteand of front view due to opposite direction of z axes on model and camera spaces. So we have to convert view to camera space inverting a z axe, that same as mirror it respectively to screen plane. So it is only significant to perform conversion only on world space to camera space conversion stage. Also we have a world space where we navigate a models and camera. For left-hand models it require a left world space. so right-hand camera navigated in left space will have opposite rotation direction (i mean world rotation that LookAt actually perform to match a world z axis with camera z axis, not a navigation of camera that performed as usual object navigation in same system that other world objects). So LookAtLH  just a same as LookAtRH but for opposite direction.  Becouse it conversion accumulated in matrice it cost zero.

Really on practicle used two methods of solwing it issue with different direction of axe.

One of it is a using left-hand system for all positions and other game mechanics calculations and convert only on related to camera tasks to perform conversion on view stage, and it primary solution for CADs and other modelling tools. Other method is to convert models to right-hand system by inverting x axe on exporting from modelling tool stage, use RH world and do not care about what system use for each operation becouse anything in RH, that often used in games.  It why libraries have 2 set of matrices constraction functions related to camera. RH set perfom no system conversion and LH set mirror/inverse camera rotations  to make RH from LH.