Well, I expect that there is a source-package with .h and .c files, and a binary-package with .so files. Not one package, just two files for one package. Installing .a and .la on user device when user doesn't need them... just consumes space and makes a mess. If there is need for debugging... then you can give to user the whole mess: .c, .h, .patch, .a, .la, .so, whatever. But the binary package for end-user should not contain additional files which are not useful at all. Right?
Yes, it is highly probable that I'm unaware of some special mission of .a and .la files. I'm not a professional debugger; for me, either program works or it doesn't. I write code in Notepad-Leafpad, compile it in command line by politely asking gcc to do it, and use the final .so or .bin file. Breakpoints don't exist for me. If debugging is necessary, I add print-or-log-or-whatever lines to my code and recompile it, to figure out later what was the problem. I dislike all these makefiles, solutions-projects, compiling environments, etcetera. And on the same level, for me .a and .la are just transient files generated by gcc for gcc. I can easily concede that separating gcc into compiler-assembler-linker-whatever is beneficial; gcc is a joyful program to use. But I have no understanding of .a and .la files - except that .so can work without them.
Best wishes.