1. If I have all 10 devices sending x, y, z rotations through rs485, are the sensors just spitting out the values and the master is catching and organizing or because it is half duplex will it lose any data?
If they just turn on their RS-485 driver enable pins without any timing sync method, eventually 2 or more will almost certainly attempt to transmit at the same time, resulting in a corrupted signal and data loss.
2. Could I just use a mix of software serial and hardware serial and receive all the data directly.
If the sensors only transmit, and the master only listens, and there's no sync mechanism to prevent 2 from transmitting simultaneously, no amount of trickery using software serial, hardware serial or other approaches will recover the lost data. When 2 transmit at the same moment, a corrupted signal will arrive, so you're going to have data loss.
The most common approach in these system is a query-response protocol, where the master transmits a query to one sensor, which then replies. Then the master transmits the query to the next sensor, and so on. All sensors hear all the queries, and when one sensor transmits, the others all hear it, so careful design of the protocol is needed so the queries are all unique and can never accidentally occur in the sensor data.
The other less common approach is called token passing. In such a system, each sensor listens for either a query from the master, or the data from the previous sensor. In normal operation, the sensors all transmit one after the next. Some token passing protocols have more complexity in the sensors, to automatically learn which sensor is the previous one, so you get back-to-back transmissions even when one goes offline. Well, except for occasional polling from the master to check if it has returned, and some strategy for it to not conflict with the next one that as learned it's missing, and.....
Usually the query-response approach is used, because it's much simpler, even though it does come with the cost of extra communication from the master to cause each sensor to transmit its data. The senors simply listen, and the master needs only a basic timeout when it tries to query a sensor that's offline. Usually masters are written to maintain a list of online sensors, so they can retry offline addresses infrequently, so avoid slowing down communication with the ones that are responding. Sensors usually have some design spec for a (hopefully short) maximum response time, which allows the master to know how long it must wait before concluding a sensor is offline.
Also, with RS-485, it's advisable to always add a brief delay before turning on the transmitter. Sensors should delay slightly before replying, and the master should delay briefly before sending another query. Those delays allow time for the other transmitter to turn off, before you turn yours on to transmit. With Serial1.transmitterEnable(), Teensy will usually control the DE pin with excellent timing. But if you later add a regular Arduino or other board into the mix, it might not be so fast. The dead time, which is sometimes called "turn around time" also allows for RS-485 repeaters to be used to extend the distance or solve star/stub cable routing (not all in a pure daisy-chain) problems.