In many situations, in the context of software development and building apps and services, various components (i.e. resources within Azure) related to a particular solution can be organised into some kind of a logical grouping. These are reflected in Azure as resource groups.
There are multiple heuristics one can use here, one obvious rule-of-thumb being that one puts such components into a single resource group which should be deployed simultaneously and form some type of an integrated solution - a functional "(sub)system" with its constituents sharing a lifecycle. The nature of ARM templates reflect this - a single template describes (the contents of) a single resource group.
Does this also apply to Logic Apps specifically? If not, what principles should one follow when making these decisions? In other words, do some best practices exist on how to organise LAs into resource groups?
Logic Apps are the sole iPaaS offering in Azure and advertised as such. Lots of experts in the field are familiar with on-premises integration products and bring in their own preconceived notions on how things are done here - in the context of these (largely, but not always) monolithic platforms.
In Azure, I have seen solutions where tens or hundreds of LAs are placed within a single RG (with an optional group for "shared" resources) - some of which are completely unrelated. And all the way from a single LA per group to attempts to create some type of a logical set of associated workflows. I'm sure no correct answer exists - but what would some of the guiding principles look like? Should LAs be treated differently than any other resource within Azure?
You should use the resource groups however best suit your organisation but with a view to future proofing the use case. A shared service resource group is not uncommon and perfectly fine to use but if your Logic App integrates with other Azure resources would you not require access to those resources also? In which case I would probably place the logic app in the same resource group as the application resources that it will be using. Shared lifecycle and shared access control for the application as a whole. Your situation may be different but this is how I would commonly set this up. Remember, you can apply different authorisation levels to the resource groups using different RBAC role assignments, e.g. logic app operator or logic app contributor.
Regarding the Azure resources to integrate with - if said resource is owned by the centralised integration team anyway e.g. a shared instance of Azure Service Bus, they can just provision it within the same "kitchen sink" group or have another one for shared services relied upon by multiple LAs. Within the context, whether there are 1 or 2 groups, does not really make a difference.
Conversely, if it is a resource owned by some other team, I think it would be strange, from the deployment perspective, to mix assets with varying ownership within the same RG. It would be more natural to just allow access (by the team owning the target resource) for a managed identity (of the LA). Or, if some other method of authentication is required - handle credentials in Azure Key Vault. The vault would be owned and administered by the centralised team - and again provisioned within the single RG along (or beside one) with the LAs requiring access to said secrets.
To clarify, I'm not questioning whether an RG for shared services (e.g. logging, monitoring, enterprise-scale message bus...) is appropriate. That is tangential to the question. I'm specifically talking about the core integration logic implemented with LAs + related resources that are not shared.
So while I do not think you have given convincing arguments to split LAs into multiple RGs in the context of a centrally managed "integration platform", I will accept your answer. As I already suspected in the beginning, the topic itself might be unsuitable for a Q&A format as there is no clear-cut answer.