Packets are only lost if an error occurs, so the answer is very much an "it depends on the noise levels" :) Only one node "owns" the bus at any time and all nodes agree on who that should be (by the end of the arbitration phase). At the end of the message there will be an acknowledgement from every node which received the message correctly and potentially a negative acknowledgement from any node which received it incorrectly. If that NAK is present, all nodes will invalidate the message and await a retry.
However, the error detection and recovery parts of CAN are only meant as a solution to random errors. In a production system, I'd be very wary of any bus which showed any error-frames at all during "normal operation".
Another thing which might be considered "packet-loss" is a regular low-priority packet, which may not be able to arbitrate its way onto the bus often enough. And if your CAN controller is FIFO-based (rather than true message-objects, each of which can arbitrate for priority internally), it may hold up higher-priority messages. Simulations of the system can help you assess how often that might occur.
In my (automotive) experience, sequence numbers are often used as a check against the software going berserk and simply transmitting the same frame over and over again. Any ACK/RETRY is left to the lower-protocol layers.
I have seen systems with a very (very!) electrically-noisy CAN bus showing several error-frames per second(!)... it worked, but had very occasional sequences of errors which causes one of the ECUs to go off the bus. Not recommended.
Another example of the error tolerance of CAN was a system which (in very early development) required a UART - the only pin available was the CAN enable pin. Even with the bus driver being turned on and off (by the UART at 115200 bps), the messages still got through. Again with a high rate of error-frames on the bus, but the retries got there in the end! And again, not recommended!
I am sure that all PCB designers have to do this all the time.
In fact, if you are designing a digital circuit with clock frequencies below about 50 MHz, you almost never will have to do signal integrity analysis to get a working design. And if you know what you are doing it is possible to design up to 1 or 2 GHz by using "best practices" rather than complex simulations.
I worked in an organization doing 1, 2, and 3 Gb/s designs and never saw a signal integrity tool in use until 2005 or so. (Although full-blown 3-d EM simulation was very occasionally used for very sticky problems)
However as the number of high-speed nets in your design increases, it's not always possible to stick to best practices everywhere, and then a simulation is valuable to indicate how much you can get away with.
Which software can be used to do this?
In contrast to what another answer said, SPICE and its derivatives are not well suited to this type of simulation. SPICE is designed for lumped-element analysis at the transistor level. In the situation you described you need to simulate a distributed element (a transmission line) and you're unlikely to have a transistor-level model of your source or load. Some SPICE-derived tools might have a signal-integrity tool bolted on, but it isn't typically what they're good at.
Signal itegrity tools generally use higher level models to reduce simulation time when simulating dozens or hundreds of distributed elements. And they can take inputs from IBIS models of the source and load ICs. These are standardized high-level macromodels that don't reveal details of the IC internals that the vendor might not want to share with all its customers.
Although I use Altium regularly I haven't used its signal integrity modelling tools. But from the description, they do seem to be IBIS-based rather than SPICE-like, so would probably work in many cases.
Another well-known tool is HyperLynx from Mentor Graphics. Cadence offers a tool set called Sigrity which I believe is similar but I have never seen or used.
Best Answer
I can't say with any certainty, but I think that for 20 to 30 cm it should work, as that length is just a small fraction of the wavelength of the data frequencies (around 10Mhz). But consider to use a ribbon cable with twice as many signals as you need (plus a couple of more) and connect every other wire to ground so that they decouple the electric field between the adjacent wires (each signal wire sees a ground wire at each side).
Use a couple of extra wires for the power and I suggest to put a small ceramic (or plastic) capacitor (something like 100n to 1u) between the VCC and GND at the microSD card's end to supply the drivers with some energy to make clean transients.
The cable will have some electromagnetic emissions, I'm afraid. But probably not so much that it would become a problem.