I am sorry to say that I wouldn’t be able to provide the required support with regard to any 3rd party Extension(s) you might be using on top of SketchUp (to a point I would say, even if in case it’s officially supported by Trimble).
There are multiple reasons to it, laying down a few;
First, let us have a look at the underlying structure of this Importer, it’s control, logic and data flows.
As you see, it’s not a very straightforward schema as you would find with most other Blender Addons.
The required data (geo-mesh, textures, material IDs et.al.) that resides in your (.skp) files are fetched inside Blender through a ‘bridge’, and this bridge is only made possible through compilation of a bunch of Cython files. These Cython files are mapped to SketchUp’s header libraries, these are mostly Data Structures written at a low-level (what we call as DNA in Blender) and you can call the slapis as RNA, a kind of.
While when you use any extensions or plugins for SketchUp, it would be most probably written in Ruby (a high-level language). Hence, the disconnect.
Second, most of these Extensions (Plug-ins and Addons, in other application’s terms) are kind of hackish methods. Many times, these would create stash objects (it could be temporary objects but necessarily not, all of the time). This creates problems when parsing such null-objects (their stored rotational values) and such.
So, I wouldn’t necessarily call it a bug from the perspective of this Importer.
The solution at hand for you: maybe you need to clean-up your file in SketchUp itself before importing (as suggested by @Balda along with purging the unused data). You can probably use another Extension to automate and speed-up that part of the process.
My foremost goal for this Importer as of now is to have all its feature working perfectly for 2.82a which used to work in 2.79b
Only after that, I can think of improvising it further (independent of any 3rd party SketchUp extensions).