1 pointI don't see any issue from the point of the LRM. From a methodology perspective, I think it depends on the abstraction level and use case you are targeting. On the side of modules representing actual hardware, I would probably prefer to have a port type stating clearly the width to have the compiler statically check for me the correct binding of ports and interfaces. For stimuli generators and monitors, a more generic base type is OK for me. Where it then interfaces with HW modules, I would insert a small adaptor. You may also consider to have a channel, which can bind to sc_int<W> and sc_int_base, and which then checks at elaboration time that the widths on all bound ports match.
1 pointThis question cannot be answered with respect to the SystemC standard as the issue is heavily implementation dependent. I am aware of implementations where SC_THREAD is faster than SC_METHOD and visa versa. It is also not a good basis for evaluating SystemC itself since the issue of simulation performance almost always comes down to how SystemC was used and how the modeler wrote their SystemC model. I do know an awful lot of folks use SystemC inappropriately (e.g. using it for modeling RTL, where VHDL or SystemVerilog are much better suited). IEEE 1666-2011 calls out the desired behavior, and not the implementation. Note: I did a presentation on SystemC myths many years ago at NASCUG that included the myth about whether or not one should favor SC_METHOD over SC_THREAD for performance reasons. It is quite simply a poor way of making a decision when attempting to obtain performance.