1) I don't think this is possible in that view. Category and Category parent are selectable but only shows one or the other.
2) I may be corrected on this but I think that the 2 views that you want to delete are default views which you can't block / delete. To make the views collasped by default you need to create a new view and set it to All Collasped. However the problem is that the user needs to select this new view from the list so that it is cached locally (and again if their views.dat fiel changes)- you cant make this new view the default. This is the way to acheive collasped views for category and classification. it is not great as you need the user to select the view first.
I can concatenate both the "Parent Category and the "Category field" into a custom field using a Database Update Rule. This leads me to believe that I can point a custom field to the higher levels of the Category tree to then concatenate them all into one.
Is there any way to populate all Category levels in the tree into custom fields, then concatenate these into one field using a DB RULE?
Wow. IMHO that is a very big category list. The list looks like it is a bit of a mixture of the CMDB, SC Categories and SC Classification Codes?.
Just in case you haven't yet considered this, if you have the CMDB populated with applications CIs etc then you can relate the Service Call to the CI. Then you should be able to keep the Service Call Category simple.
I have attached our SC category, classification and Closure Codes - but I am not saying these are correct as it is more about what your reporting needs are. With a well thought out SC Categories, Classifications, CIs and CI Categories, the combination would possibly provide what your category list provides and would be much easier to maintain in the long term.